Wer im Juni dieses Jahres den Patch für seine Zyxel-GS1900-Switches eingespielt hat und sich seither in Sicherheit wähnte, sollte die Firmware-Version noch einmal prüfen. Nach der Analyse von Binarly schließt der damalige Fix nicht die Lücke, über die Angreifer die Geräte seit dem Spätsommer tatsächlich kompromittieren. Zyxel hat am 3. November 2026 nachgezogen und für zehn GS1900-Modelle eine neue Patch-Stufe .3 veröffentlicht, die als Zielmarke des aktiven Exploits gilt. Die Schwachstelle trägt die Kennung CVE-2026-107441.

Ein Patch, der am eigentlichen Problem vorbeiging

Die Geschichte beginnt im Juni: Zyxel beschreibt für die GS1900-Serie einen Stack-basierten Buffer-Overflow (CVE-2026-7273) im CGI-Programm der Switches und liefert eine Firmware, die eine fehlende Prüfung der Parameteranzahl nachholt. Im September meldet GreyNoise die Ausnutzung der Lücke – nach eigenen Angaben nahezu 1.000 Geräte in 48 Ländern. Binarly nimmt sich den Exploit vor und findet: Die beobachteten Angriffe triggern gar nicht die von Zyxel adressierte Bedingung. Angreifer korrumpieren einen Parameter-Zähler vor der Validierung und erreichen über einen anderen Pfad dieselbe unauthentifizierte Code-Ausführung.

Binarly meldet den Befund am 29. September an Zyxel, der Hersteller bestätigt am 11. Oktober, am 22. Oktober erscheint die korrigierte Firmware. Zyxel beschreibt die neue Schwachstelle als „out-of-bounds write" im CGI-Programm und trennt sie klar von der Juni-Lücke: Der alte Patch habe eine fehlende Mengen-Prüfung ergänzt, die neue Lücke drehe sich um die fehlende Größen-Prüfung einzelner Parameter. Der Angreifer braucht auch hier keine Anmeldung – ein präpariertes HTTP-Request an das Verwaltungsinterface reicht.

Netzwerk-Switch mit Patchkabeln in einem Computerlabor

Bild: Network Device (Switch) von JBequio, Lizenz CC BY 4.0, via Wikimedia Commons.

Betroffene Modelle und die konkreten Versionen

Zyxel nennt im Advisory zehn Modelle. Verwundbar ist jeweils die Firmware .2-Stand (und älter), gepatcht die neue .3-Stufe:

  • GS1900-8: 2.90(AAHH.2)C0 und älter – Fix in 2.90(AAHH.3)C0
  • GS1900-8HP: 2.90(AAHI.2)C0 und älter – Fix in 2.90(AAHI.3)C0
  • GS1900-10HP: 2.90(AAZI.2)C0 und älter – Fix in 2.90(AAZI.3)C0
  • GS1900-16: 2.90(AAHJ.2)C0 und älter – Fix in 2.90(AAHJ.3)C0
  • GS1900-24: 2.90(AAHL.2)C0 und älter – Fix in 2.90(AAHL.3)C0
  • GS1900-24E: 2.90(AAHK.2)C0 und älter – Fix in 2.90(AAHK.3)C0
  • GS1900-24EP: 2.90(ABTO.2)C0 und älter – Fix in 2.90(ABTO.3)C0
  • GS1900-24HPv2: 2.90(ABTP.2)C0 und älter – Fix in 2.90(ABTP.3)C0
  • GS1900-48: 2.90(AAHN.2)C0 und älter – Fix in 2.90(AAHN.3)C0
  • GS1900-48HPv2: 2.90(ABTQ.2)C0 und älter – Fix in 2.90(ABTQ.3)C0

Der Modell-Code in der Mitte der Versionsnummer (etwa AAHH für den GS1900-8) ist gerätespezifisch. Wer sich beim Vergleich unsicher ist, orientiert sich an der Ziffer vor )C0: .3 ist aktuell, alles darunter muss aktualisiert werden.

Firmware-Version korrekt prüfen

Die Versionsnummer steht im Web-Interface des Switches unter System → System Information oder Maintenance → Firmware. Wer mehrere Switches betreibt, kommt schneller über SNMP oder die Standard-Credentials-Datei zum Ziel, muss aber genau hinsehen: Zyxel führt bei den GS1900 die Modellkennung in Klammern. Eine simple Prüfung auf 2.90 reicht nicht, weil sowohl .1, .2 als auch .3 zur selben Hauptversion gehören. Zu prüfen ist die Teilziffer vor dem )C0-Suffix.

Praxis-Tipp: Zyxels Advisory listet die Modellbezeichner, aber keine gemeinsame Zeichenfolge, auf die sich grobes Scripting stützen könnte. Ein kurzer Shell-Zweizeiler, der die Zieldatei der Backup-Ablage prüft, hilft nur, wenn die Gerätekonfigurationen zentral abgelegt sind. Sonst führt an der manuellen Sichtung je Switch kein Weg vorbei.

Was du jetzt tun solltest

  1. Firmware-Version aller GS1900-Switches erheben. Nicht nur die Modellnamen, sondern die vollständige Zeichenkette inklusive (XXXX.N)C0. Alles unterhalb von .3 ist angreifbar.
  2. Patch 3 einspielen. Der direkte Firmware-Link steht im Zyxel-Advisory vom 3. November 2026. Vor dem Update: Konfiguration sichern (Management → Configuration → Backup).
  3. Verwaltungsinterface nicht ins Internet hängen. Das sollte ohnehin gelten, ist bei der aktiven Ausnutzung aber die einzige Gegenmaßnahme für Geräte, die (noch) nicht gepatcht werden können. Der Exploit setzt Netzwerkzugriff auf das CGI voraus – wer das Interface per Firewall oder VLAN auf ein dediziertes Management-Netz beschränkt, verkleinert die Angriffsfläche erheblich.
  4. Kompromittierung ausschließen. Nach dem Patch: Logs des Switches auf unerwartete Konfigurationsänderungen prüfen, neue Nutzer, geänderte SNMP-Communities, neu angelegte VLANs oder Trunk-Ports. Ein kompromittierter Switch kann Datenverkehr spiegeln oder umlenken, ohne dass das Gerät selbst sichtbar abstürzt.

Lehrstück: Ein Patch kann die falsche Lücke schließen

Der Fall GS1900 ist aus mehreren Gründen bemerkenswert. Erstens war der Juni-Patch nicht „falsch" im Sinne eines unwirksamen Fixes – er schloss tatsächlich eine Lücke, nur eben nicht diejenige, die im Feld ausgenutzt wurde. Zweitens offenbart die Fehlermeldung von GreyNoise im September („Exploit für CVE-2026-7273 beobachtet") ein Zuordnungsproblem, das in der Praxis häufig auftritt: Wer nur die CVE-Nummer sieht, kann nicht unterscheiden, ob der Angriff die dokumentierte Logik trifft oder eine verwandte Schwäche. Erst die genauere Analyse der Payload – im Fall Binarly ein Reverse-Engineering des Patches und ein Vergleich mit dem beobachteten Request – deckte die Diskrepanz auf.

Für Admins bedeutet das: Ein Patch beseitigt nicht automatisch die Grundlage eines beobachteten Exploits, auch wenn beide dieselbe Produktfamilie betreffen. Belastbar ist nur ein Vergleich der eigenen Firmware mit der vom Hersteller genannten Zielversion – und, wo verfügbar, die unabhängige Bestätigung durch Forscher-Analysen wie die von Binarly. Zyxel verdankt die Korrektur den Binarly-Analysten Yegor Vasilenko und Fernando Mercês, die ihre Entdeckung koordiniert gemeldet haben.

Quellen

Bildnachweis