Zyxel referme le zero-day CVE-2026-107441 que son patch de juin n’avait pas corrigé sur les switchs GS1900

16 juin 2026. Zyxel publie un correctif pour CVE-2026-7273, un dépassement de tampon pré-authentification dans le programme CGI des switchs GS1900. 21 septembre 2026. GreyNoise attribue la compromission de 996 équipements dans 48 pays à cette faille, et la CISA l’ajoute à son catalogue KEV. 28 septembre 2026. Les chercheurs de Binarly découvrent que l’exploit réel continuait de fonctionner sur les dix firmwares déjà corrigés. Pourquoi c’est important : le patch de juin fermait une porte que les attaquants n’utilisaient pas — la vraie brèche, CVE-2026-107441, est restée ouverte quatre mois de plus.

Un correctif pour la mauvaise faille

Le 16 juin 2026, Zyxel diffusait un firmware corrigeant CVE-2026-7273, un stack-based buffer overflow dans le programme CGI de l’interface web des switchs GS1900, exploitable par un attaquant non authentifié sur le LAN. L’affaire semblait réglée. Elle ne l’était pas.

Le 21 septembre, GreyNoise rend publique une campagne menée par un acteur sinophone suivi sous le nom de Kapibala, lié à la campagne Red Heron décrite par Acronis — celle qui avait déjà exploité une faille dans Gitea et déposé le rootkit SIXZUT. GreyNoise comptait 996 appareils compromis dans 48 pays, avec exfiltration des configurations, des identifiants root hachés et des informations réseau. La CISA réagit le jour même en ajoutant CVE-2026-7273 au KEV. Tout le monde crut que le correctif de juin avait simplement été ignoré par des administrateurs en retard.

Binarly a prouvé le contraire. En enquêtant sur l’infrastructure Red Heron liée au backdoor JITTERLY, ses chercheurs ont trouvé un répertoire ouvert hébergeant une archive gs1900_bundle.tar.gz. Elle contenait un exploit prêt à l’emploi : un script Python 3.10, exp.py, obfusqué avec PyArmor, accompagné de sa runtime et de son bytecode. L’exploit cible /cgi-bin/dispatcher.cgi, le CGI de gestion web des GS1900.

Ce que l’exploit révèle sur la brèche réelle

Deux détails ont mis la puce à l’oreille des chercheurs. D’abord, l’exploit vérifie explicitement que le firmware exécute les versions corrigées pour CVE-2026-7273 — signe qu’il a été écrit ou mis à jour pour contourner ce patch précis. Ensuite, testé sur les dix firmwares portant le correctif de juin, il obtenait toujours une exécution de commandes sans authentification.

Le mécanisme est fin. Le correctif de juin ajoutait des contrôles pour bloquer le débordement de tampon. Les attaquants ont contourné ces contrôles en corrompant le compteur de paramètres avant sa validation — une technique qui permet d’écraser la mémoire et d’exécuter des commandes malgré la présence du patch. C’est un défaut distinct, que Zyxel a confirmé le 11 octobre 2026 sous le numéro CVE-2026-107441 : un out-of-bounds write dans le programme CGI, couplé à une validation manquante de la longueur des paramètres HTTP.

Binarly l’a signalé à Zyxel le 29 septembre. Le constructeur a publié le nouveau firmware le 22 octobre, puis son avis de sécurité le 3 novembre. La faille touche les dix modèles de la gamme GS1900.

La chronologie qui a trompé tout le monde

L’enchaînement vaut d’être mémorisé, car il explique pourquoi personne n’a réagi à temps :

• 16 juin 2026 — Zyxel corrige CVE-2026-7273 dans les firmwares 2.90 Patch 2 (XXXX.2)C0).
• 17 août 2026 — GreyNoise commence à observer Kapibala exploiter les GS1900 en conditions réelles.
• 21 septembre 2026 — GreyNoise divulgue la campagne et l’attribue à CVE-2026-7273 ; la CISA ajoute la CVE au KEV.
• 28 septembre 2026 — Binarly confirme que l’exploit contourne le correctif sur les dix firmwares patchés.
• 29 septembre / 11 octobre 2026 — signalement à Zyxel, puis confirmation de la nouvelle CVE CVE-2026-107441.
• 22 octobre 2026 — publication des firmwares 2.90 Patch 3 (XXXX.3)C0).
• 3 novembre 2026 — publication de l’avis de sécurité officiel.

Pendant cette fenêtre, un administrateur consciencieux qui avait appliqué le patch de juin était toujours vulnérable — et n’avait aucune raison de le soupçonner.

Ce qu’il faut faire maintenant

Tout GS1900 tournant sur un build 2.90 Patch 2 (XXXX.2)C0) ou antérieur est vulnérable à CVE-2026-107441. Le correctif est dans les firmwares 2.90 Patch 3. La montée de version est la priorité, mais elle ne suffit pas.

Un équipement compromis avant la mise à jour ne se « répare » pas en patchant. Les attaquants ont exfiltré des configurations et des hashs de root — de quoi établir une persistance ou se déplacer latéralement sur le réseau. Pour chaque switch concerné, il faut donc chercher des traces de compromission avant de le remettre en production :

# Vérifier la version de firmware embarquée
show version

# Rechercher des sessions ou comptes inhabituels dans la configuration
show running-config | include username

La règle simple : si le switch a été exposé sur le LAN à un réseau non fiable — ou si son interface de gestion était joignable depuis un segment qu’on ne maîtrise pas — traitez-le comme suspect jusqu’à preuve du contraire.

La leçon : les numéros de version ne sont pas une preuve

L’épisode illustre une vérité inconfortable pour toute équipe réseau. Les avis de sécurité et les numéros de version aident, mais ils ne peuvent pas être crus aveuglément. Binarly le formule ainsi : la seule façon définitive de savoir si un logiciel contient une vulnérabilité est d’examiner son code binaire.

Deux aspects rendent l’affaire plus inquiétante encore. D’une part, Binarly estime que l’exploit a probablement été généré par un LLM — les modèles donnent aux attaquants la capacité d’itérer vite sur des contournements de patch. D’autre part, la confusion entre CVE-2026-7273 et CVE-2026-107441 a fait perdre quatre mois de réaction, pendant lesquels l’attribution officielle pointait vers une faille déjà corrigée.

C’est un signal pour la gestion de parc : un inventaire précis des firmwares réellement exécutés, pas des versions déclarées, est la seule ligne de défense. Quand un correctif est attribué à une campagne active, la bonne question n’est pas « suis-je patché ? » mais « ce patch ferme-t-il bien ce que l’attaquant exploite ? ».

Verdict

Cette affaire n’est pas une simple vulnérabilité de plus dans un switch d’entrée de gamme. C’est une défaillance du chaînage correctif → attribution → confiance : un correctif publié à temps, une campagne attribuée à la mauvaise CVE, et une brèche réelle restée béante pendant des mois sous le nez de tous.

Si vous exploitez des switchs GS1900, montez immédiatement en firmware 2.90 Patch 3 et menez une chasse à la compromission sur chaque équipement exposé — le correctif de juin ne protégeait pas contre ce qui s’est réellement passé. Pour le reste de votre parc, exigez que chaque CVE attribuée à une campagne soit vérifiée contre le binaire exécuté, pas contre le numéro de version — car la confiance dans les avis est précisément ce que cette attaque a exploité.

Références

• BleepingComputer — Zyxel fixes zero-day exploited to hack nearly 1,000 network switches (4 novembre 2026)
• Help Net Security — Patched Zyxel GS1900 switches remained open to in-the-wild exploit (CVE-2026-107441) (5 novembre 2026)
• Binarly — Zyxel GS1900 RCE CVE-2026-107441
• Zyxel — Security advisory for out-of-bounds write vulnerability in GS1900 series switches (3 novembre 2026)
• Zyxel — Security advisory for stack-based buffer overflow vulnerability in GS1900 series switches (16 juin 2026)