Gepatcht und trotzdem offen: Wie ich meinen Zyxel-Switch auf die GS1900-Lücke abgeklopft habe

Podcast zum Blogbeitrag:

Du kennst das: Der Hersteller meldet eine Lücke, du spielst brav das Update ein, haken dran, nächstes Ticket. Bei der Zyxel GS1900 Sicherheitslücke hätte genau das nicht gereicht. Wer im Juni ordentlich gepatcht hat, war danach genauso angreifbar wie vorher – nur mit besserem Gefühl.Anfang November hat Zyxel deshalb nachgelegt: CVE-2026-107441, ausgenutzt in freier Wildbahn, betroffen ist praktisch die ganze GS1900-Serie. Die Dinger stehen in Schulen, Arztpraxen, kleinen Firmen und – in meinem Fall – im Keller. Mein GS1900-24EP versorgt dort NAS, Access Points und den Rest per Kabel und PoE.Ich wollte nicht einfach nur patchen, sondern vorher wissen: Hat sich da schon jemand bedient? Hier ist mein Ablauf, Schritt für Schritt, mit dem, was ich gefunden habe – und dem, was ich bewusst nicht weiß.

Ziel

• Prüfen, ob ein GS1900 betroffen ist.
• Spuren sichern, bevor ein Neustart sie löscht.
• Sauber auf die korrigierte Firmware aktualisieren, mit Rückweg.
• Den Switch so härten, dass die nächste Lücke weniger Angriffsfläche findet.

Voraussetzungen

• Ein Zyxel GS1900 im Standalone-Betrieb (Weboberfläche).
• Ein Rechner im selben Netz mit tcpdump (bei macOS dabei) und nc.
• Optional: ein Router, der Pakete mitschneiden kann (bei mir eine FRITZ!Box), und ein Syslog-Empfänger (bei mir das Protokoll-Center einer Synology).
• Ein Wartungsfenster von 15 Minuten. Der Switch startet neu, und alles, was per PoE an ihm hängt, gleich mit.

Was hinter der Zyxel GS1900 Sicherheitslücke steckt

Die Fakten aus Zyxels Advisory vom 3. November und der Analyse von Binarly, die die Lücke gemeldet haben:

• CVE-2026-107441, Schreiben außerhalb eines Puffers (CWE-787), CVSS 8,8 laut Zyxel.
• Betroffen ist das CGI-Programm dispatcher.cgi hinter der Weboberfläche. Es verarbeitet die Formulardaten jeder Anfrage.
• Keine Anmeldung nötig. Eine einzige präparierte HTTP-Anfrage reicht, um Befehle auf dem Switch auszuführen.
• Der Angreifer muss die Weboberfläche erreichen. Zyxel nennt das „LAN-based“, im CVSS-Vektor steht AV:A.

Technisch läuft es so: Die Funktion, die die Formulardaten zerlegt, schreibt jedes Feld in einen festen Speicherbereich mit 140 Plätzen zu je 1.024 Byte. Sie prüft weder, wie lang ein Feld ist, noch, wie viele Felder schon gelesen wurden. Ein überlanges Feld überschreibt deshalb den Feldzähler, der direkt dahinter im Speicher liegt – und ab da kann der Angreifer an fast beliebige Stellen schreiben. Den Rest erledigt ein umgebogener Funktionsaufruf.

Warum der Juni-Patch nicht geholfen hat

Im Juni hatte Zyxel eine ähnlich klingende Lücke geschlossen (CVE-2026-7273), und die US-Behörde CISA hat dazu aufgefordert, das Update einzuspielen. Binarly hat sich den Patch angesehen: Die neuen Prüfungen greifen erst, nachdem der Zähler schon überschrieben ist. Der Exploit, den sie auf einem Server der Angreifer gefunden haben, enthielt sogar schon die Speicheradressen der „gepatchten“ Juni-Firmware. Er lief darauf unverändert.Laut Berichten kopieren die Angreifer die Konfiguration und die Passwort-Hashes der Switches. Auf ihrem Server lagen außerdem eine Hintertür und ein Rootkit, die dieselbe Gruppe bei anderen Angriffen einsetzt. Das ist das eigentlich Unangenehme: Ein übernommener Switch fällt nicht auf. Der läuft einfach weiter.

Bin ich betroffen?

Die Firmware steht in der Weboberfläche auf der Startseite unter Device Information → Firmware Version. Betroffen ist alles bis einschließlich der „.2“-Version, behoben ist es in der „.3“:

Modell	Betroffen bis	Korrigiert in
GS1900-8	2.90(AAHH.2)C0	2.90(AAHH.3)C0
GS1900-8HP	2.90(AAHI.2)C0	2.90(AAHI.3)C0
GS1900-10HP	2.90(AAZI.2)C0	2.90(AAZI.3)C0
GS1900-16	2.90(AAHJ.2)C0	2.90(AAHJ.3)C0
GS1900-24	2.90(AAHL.2)C0	2.90(AAHL.3)C0
GS1900-24E	2.90(AAHK.2)C0	2.90(AAHK.3)C0
GS1900-24EP	2.90(ABTO.2)C0	2.90(ABTO.3)C0
GS1900-24HPv2	2.90(ABTP.2)C0	2.90(ABTP.3)C0
GS1900-48	2.90(AAHN.2)C0	2.90(AAHN.3)C0
GS1900-48HPv2	2.90(ABTQ.2)C0	2.90(ABTQ.3)C0

Mein Switch lief auf der Juni-Version. Also genau die Version, mit der man sich sicher fühlen durfte.Wie gefährlich das konkret ist, hängt davon ab, wer die Weboberfläche erreicht. Bei mir: aus dem Internet niemand, der Router gibt nur die NAS frei. Aus dem Heimnetz dagegen jedes Gerät. Und in einem Heimnetz hängen Kamera, Fernseher, Smart-Home-Kram – also genau die Geräte, die selbst gern mal übernommen werden. In einer Schule oder Firma ohne eigenes Verwaltungs-VLAN sieht es nicht besser aus.

Schritt 1: Spuren sichern, bevor du patchst

Der Reflex ist: sofort updaten. Ich würde vorher fünf Minuten investieren. Das Update startet den Switch neu, und alles, was nur im Arbeitsspeicher lebt, ist danach weg – auch eine Hintertür, die sich nicht dauerhaft eingenistet hat.In der Weboberfläche checke ich drei Dinge:

1. Konten: Configuration → Management → Users. Gibt es nur die Konten, die du kennst?
2. Dienste: Configuration → Management → HTTP/HTTPS, TELNET/SSH, SNMP. Ist irgendwo etwas an, das du nie eingeschaltet hast?
3. Systemprotokoll: Monitor → Management → Syslog, Ziel „Buffered“ und „Flash“, alle Stufen, View. Achtung, direkt daneben liegt Clear.

Die Konfiguration selbst sicherst du unter Maintenance → Configuration → Backup, Methode HTTP, „Running configuration“. Die Datei enthält den Passwort-Hash, also nicht herumliegen lassen.In meinem Fall: ein Konto, Telnet, SSH und SNMP aus, keine fremden Einträge in der Konfiguration. Im Protokoll standen genau zwei Anmeldungen, beide von meinem Rechner.Wichtig: Das ist kein Freispruch. Der Angriff braucht keine Anmeldung und hinterlässt deshalb auch keinen Anmeldeeintrag. Ein sauberes Protokoll heißt nur: Hier hat sich niemand mit Passwort angemeldet.

Schritt 2: Den Switch belauschen

Mehr Aussagekraft hat der Netzwerkverkehr. Eine Hintertür will nach Hause telefonieren, und das läuft über den Router. Die FRITZ!Box kann das mitschneiden: Die Seite Paketmitschnitt steht nicht im Menü. Unter FRITZ!OS 8 erreichst du sie angemeldet über http://fritz.box/#/cap, bei älteren Versionen über /html/capture.html. Dort startest du den Mitschnitt auf der Schnittstelle lan, weil du da noch die internen Adressen siehst. Die Datei landet im Download-Ordner. Ich habe 15 Minuten laufen lassen, das waren gut 700 MB.Danach filterst du den Switch heraus:

tcpdump -nn -r fritzbox-lan.eth -w switch.pcap 'host 192.0.2.24'
tcpdump -nn -tttt -r switch.pcap

Und prüfst gleich das ganze Netz gegen die Indikatoren, die Binarly veröffentlicht hat (Domain der Kommandoserver und deren IP-Adressen):

# DNS-Anfragen nach der Angreifer-Domain
tcpdump -nn -A -r fritzbox-lan.eth 'udp port 53' | grep -c 981666

# Verbindungen zu den bekannten Kommandoservern
tcpdump -nn -r fritzbox-lan.eth \
  'host 104.223.65.148 or host 203.88.123.148 or host 104.225.153.141 or host 166.88.227.181' | wc -l

Bei mir kam vom Switch in 15 Minuten genau ein Paket: eine ARP-Anfrage. Keine DNS-Abfrage, keine Verbindung nach draußen. Und im ganzen Netz keine einzige Anfrage an die bekannten Server.Hinweis: Damit du nicht einem leeren Mitschnitt vertraust, zählst du zum Vergleich die Pakete eines Geräts, das sicher aktiv war. Bei meinem Mac waren es rund 56.000.

Schritt 3: Update mit Rückweg

Die GS1900 haben zwei Firmware-Speicherplätze. Das nutzen wir aus:

1. Firmware bei Zyxel im Download-Bereich zu deinem Modell holen (ZIP mit .bix-Datei und Release Note). In der Release Note muss stehen: „Fixed Pre-authentication out-of-bounds write vulnerability (CVE-2026-107441)“.
2. Maintenance → Firmware → Upload, Methode HTTP, Image Backup, Datei wählen, Apply. Das alte Image bleibt aktiv.
3. Firmware → Management: die neue Version als Active Image wählen, Apply.
4. Maintenance → Reboot.

Rechne mit zwei bis drei Minuten Ausfall. Alles mit PoE geht mit runter: Bei mir waren auch das WLAN und die Kamera kurz weg.Danach wieder prüfen: Auf der Startseite steht die neue Version, und die laufende Konfiguration sollte identisch zu deiner Sicherung aus Schritt 1 sein. War sie bei mir.

Schritt 4: Härten, solange du eh dran bist

• Neues Admin-Passwort. Die Angreifer haben bei dieser Kampagne gezielt Hashes kopiert. Nach dem Patch ist ein neues Passwort Pflicht, nicht Kür. Danach Save oben in der Leiste, sonst ist es nach dem nächsten Neustart weg.
• HTTP aus, nur HTTPS. Ändert nichts an der Lücke (die steckt auch hinter HTTPS), aber dein Passwort geht nicht mehr im Klartext durchs Netz. Mach das aus einer HTTPS-Sitzung heraus, siehe Stolperstellen.
• Verwaltung eingrenzen. In Netzen mit Verwaltungs-VLAN gehört die Management-IP genau dorthin, dazu Remote Access Control auf die Admin-Rechner. Wie man das in der Schule aufzieht, habe ich in „VLAN-Segmentierung in der Schul-IT“ beschrieben. Im flachen Heimnetz habe ich es gelassen: Die Gefahr, mich auszusperren, war größer als der Nutzen.
• Protokolle nach draußen. Configuration → Management → Syslog → Remote, Server eintragen, Stufe „info“. Bei mir nimmt das Protokoll-Center der Synology auf UDP 514 an. Dann überlebt das Protokoll auch einen Neustart, und ein Angreifer kann es nicht mehr so einfach wegputzen.

Und die Access Points?

Am selben Tag hat Zyxel auch eine Lücke in vielen Access Points gemeldet: CVE-2026-76955, ein Pufferüberlauf im Dienst zdp_wtp, mit dem sich ein Angreifer im LAN höhere Rechte verschaffen kann. Bei einem NWA210AX ist sie in 7.12(ABTD.1) behoben.Meine beiden APs werden über Nebula verwaltet. Die hatten das Update schon am 26. Oktober automatisch bekommen, also eine Woche vor der Meldung. Das ist der angenehme Teil von Cloud-Verwaltung.Der weniger angenehme: Unter Konfigurieren → Allgemeine Einstellung → Gerätekonfiguration waren für den lokalen Zugang SSH, HTTP, HTTPS, FTP und SNMPv2 mit voreingestellter Community eingeschaltet, ohne IP-Beschränkung. Bei cloudverwalteten APs brauchst du lokal praktisch nie etwas. Ich habe alles bis auf HTTPS als Notzugang abgeschaltet:Danach habe ich nachgemessen, ob die Ports an den Geräten wirklich zu sind:

for ip in 192.0.2.44 192.0.2.46; do
  for p in 21 22 80 443; do
    nc -z -G 2 $ip $p && echo "$ip tcp/$p offen" || echo "$ip tcp/$p zu"
  done
done

Im selben Menü gibt es übrigens auch einen Syslog-Server. Damit landen die AP-Protokolle mit auf der NAS.

So prüfst du es

• Startseite des Switches: Firmware steht auf der „.3“-Version.
• curl -s -m 5 http://192.0.2.24/ läuft ins Leere, curl -sk https://192.0.2.24/ liefert 200.

• Im Syslog-Empfänger taucht nach deiner nächsten Anmeldung ein Eintrag des Switches auf. Bei mir war der erste Eintrag ausgerechnet das Abschalten des HTTP-Dienstes.

Rückweg

Falls nach dem Update etwas klemmt: Maintenance → Firmware → Management, das alte Image als Active Image wählen, neu starten. Die Konfiguration bleibt erhalten. Das alte Image ist allerdings die angreifbare Version, also nur als Notlösung, bis du die Ursache hast.

Stolperstellen aus der Praxis

• Sauberes Protokoll ist kein Freispruch. Die Lücke braucht keine Anmeldung, also gibt es auch keinen Anmeldeeintrag. Aussagekräftiger ist der Netzwerkverkehr.
• Erst sichern, dann neu starten. Der Neustart beim Update löscht alles, was nur im Speicher liegt.
• HTTP nicht aus einer HTTP-Sitzung abschalten. Nach Apply ist die Verbindung weg, und du kommst nicht mehr an Save. Also erst per HTTPS anmelden, dann abschalten, dann speichern.
• Selbst signiertes Zertifikat. Der Switch hat ab Werk ein Zertifikat mit „My Organization“ drin. Safari lässt dich nach einer Warnung durch, manche Browser und Werkzeuge gar nicht. Prüf das, bevor du HTTP abschaltest.
• Zeitlimit von drei Minuten. Die Weboberfläche meldet dich nach drei Minuten ohne Aktivität ab. Wer nebenbei Release Notes liest, meldet sich öfter an.
• Konfigurations-Backup ist Einweg. Die Sicherungsdatei liegt nur kurz auf dem Switch und wird nach dem Abruf gelöscht. Einfach erneut anfordern.
• PoE hängt mit dran. Access Points, Kameras und Telefone am Switch starten mit neu. Bei mir hat der Neustart auch die Laufzeit der APs auf null gesetzt, was später in deren Diagnose wieder auftauchte.
• Nebula setzt großzügige Standards. Lokaler Zugang mit allen Diensten und SNMPv2 mit voreingestellter Community war bei meinen APs an. Einmal durchklicken lohnt sich.
• Zyxel-Mails zu „ungewöhnlichen Anmeldungen“. Die kommen vom Nebula-Konto, nicht vom Switch. Bei mir waren es meine eigenen Anmeldungen. Den Verlauf siehst du über den Link „Letzter Login“ unten in Nebula.

Was belegt ist und was nicht

• Belegt: betroffene Firmware, keine fremden Konten oder Dienste, keine fremden Konfigurationseinträge, kein Verkehr vom Switch nach draußen, kein Kontakt zu den bekannten Kommandoservern im Mitschnittzeitraum. Die APs hatten keine Absturzabbilder und keine fremden Änderungen.
• Nicht belegt: dass der Switch nie angegriffen wurde. Verkehr zwischen Switch und anderen Geräten im LAN sieht der Router nicht, und 15 Minuten schließen seltene Verbindungen nicht aus.
• Meine Einschätzung: mit hoher Wahrscheinlichkeit nicht kompromittiert. Ein Switch, der aus dem Internet nicht erreichbar ist, ist eben kein naheliegendes Ziel für eine Kampagne, die massenhaft scannt.

Fazit

Die eigentliche Lektion der Zyxel GS1900 Sicherheitslücke ist nicht der Pufferüberlauf, sondern der Juni-Patch. Ein Update, das die Versionsnummer ändert, ist noch kein Beweis, dass die Lücke weg ist. Für uns Admins heißt das: Release Notes lesen, Meldungen eine Weile im Blick behalten und Netzwerkgeräte nicht als Möbel betrachten, sondern als Rechner mit Weboberfläche. Die Weboberfläche gehört in ein Verwaltungsnetz, die Protokolle auf einen anderen Rechner, und vor dem Neustart sicherst du die Spuren. Dann ist der nächste Patch-Montag zwar nicht spannender, aber deutlich entspannter.Wer seine Passwörter für Switch und APs dann noch in einem selbst gehosteten Passwortmanager ablegt, sollte auch den sichern. Wie das geht, steht in „Passwortmanager weg, Backup auch?“.Quellen: Zyxel Security Advisory zu CVE-2026-107441 (03.11.2026) · Binarly: Pre-Auth RCE in Zyxel GS1900 Exploited in the Wild as a Zero-Day · NVD: CVE-2026-107441 · Zyxel Security Advisory zu CVE-2026-76955 (Access Points) · heise: Angriffe auf Zyxel-Switches