Zyxel GS1900 CVE-2026-107441: the June Patch Didn't Hold

Zyxel has assigned a second CVE to its GS1900 smart-managed switches and shipped new firmware, because the fix it published in June never actually closed the hole. CVE-2026-107441 is an out-of-bounds write in the switch's web-management CGI that lets a LAN-adjacent, unauthenticated attacker run operating-system commands with one crafted HTTP request — the same reach as CVE-2026-7273, the June flaw that GreyNoise watched being used to compromise nearly a thousand switches worldwide. Binarly's researchers found that the June patch could be walked straight through, told Zyxel, and now there is a new advisory, a new CVE and new firmware. If you patched GS1900 switches in the summer and closed the ticket, that ticket is open again.

Developing story — first published 08:31 CET (07:31 UTC), 5 November 2026. Updated as Zyxel, Binarly and CISA publish more.

At a glance

CVE	CVE-2026-107441
Product / affected versions	Zyxel GS1900 series smart-managed switches — 10 models; firmware 2.90(…​.2)C0 and earlier (per-model strings below)
Fixed in	Per-model firmware 2.90(…​.3)C0, released 2026-10-22 (full table in Remediation)
CVSS	8.8 HIGH · CVSS 3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · scored by Zyxel; Binarly rates it 9.8 Critical, arguing it is reachable over plain HTTP from anywhere that can reach the switch; NVD "Awaiting Analysis", no NIST score yet
Weakness	CWE-787 out-of-bounds write in the web-management CGI (dispatcher.cgi)
Exploited in the wild	The GS1900 campaign (996 devices · 48 countries, GreyNoise) was attributed to CVE-2026-7273; Binarly showed that patch was bypassable, so which flaw the campaign actually rode is unconfirmed
CISA KEV	Not listed (catalog 2026.11.04); the sibling CVE-2026-7273 was added 2026-09-21
Official advisory	Zyxel advisory, 2026-11-03

A patch that didn't hold

In June, Zyxel patched CVE-2026-7273, a stack-based buffer overflow in the GS1900 web-management CGI that gave a LAN-based, unauthenticated attacker OS command execution through a single HTTP request. In September, BleepingComputer reported GreyNoise's finding that a Chinese-speaking actor — tracked as Kapibala and tied to the Red Heron campaign — had used that flaw to compromise 996 GS1900 switches across 48 countries, extracting device configurations, network information and hashed root credentials. CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities catalog on 21 September.

The problem: the June fix added validation, but in the wrong place. While mapping Red Heron infrastructure, Binarly's researchers found an obfuscated, likely LLM-generated Python exploit for GS1900 switches on an exposed attacker directory, and discovered it still worked against all ten firmware releases that had been patched for CVE-2026-7273. Per Binarly's analysis, as relayed by securityonline, the dispatcher.cgi web handler stores incoming HTTP parameters in a fixed block of 140 slots of 1,024 bytes each and copies the data in before checking the parameter count. An oversized value in the last slot overruns the buffer and overwrites the parameter counter itself; the resulting negative count lets the attacker write to memory ahead of the block, overwrite function pointers, and run OS commands as root. Zyxel's June patch added a count check — but the check runs after the oversized parameter has already been copied, and it never validated the length of an individual field. That distinct, unaddressed root cause is why Zyxel assigned a separate CVE, CVE-2026-107441. (Binarly also notes the corrupted buffer lives in global memory, not the stack, so the original "stack-based overflow" label was itself imprecise.)

Binarly's Yegor Vasilenko and Fernando Mercês reported it to Zyxel on 29 September; Zyxel assigned the CVE on 11 October, shipped firmware on 22 October, and published its advisory on 3 November. The October firmware caps each copied field and validates the parameter count before copying data into memory — the fix the June patch should have been.

That sequence is the whole lesson. Whether the in-the-wild campaign rode the original overflow or the bypass is unconfirmed — but the operational outcome is the same for defenders who applied the June firmware: the mitigation they trusted did not stop the technique.

"We patched that one in June." That sentence is the trap. A patch is a claim that a specific code path is now safe. Here the path was still reachable, and the only way to know was to run the exploit against the patched build — which is exactly what Binarly did and the defenders who deployed the June firmware did not.

Who is exposed

GS1900 switches are smart-managed Layer-2 switches sold by the hundreds of thousands into small and mid-sized networks, branch offices and wiring closets. Zyxel scores the attack AV:A — LAN-adjacent — so on paper the exposure is whoever can reach the switch's web-management interface. Binarly disputes that framing and scores it 9.8, on the grounds that it is reachable over plain, unauthenticated HTTP from any network path to the switch; a GS1900 whose management UI is exposed to a wider segment, a flat office network, or the internet is effectively network-remote. Either way, the population that got hit tells the real story: of the 996 compromised switches GreyNoise counted, 564 were still on factory-default logins, and the heaviest concentrations were in Italy, the United States and Taiwan. Plenty of these interfaces are reachable from places they should not be, by attackers who did not even need the bug to log in.

Remediation

Am I affected?

Check the running firmware on each GS1900 switch (web UI: Monitor → System Information, or the switch CLI). You are affected if the version is at or below the per-model 2.90(…​.2)C0 string in the table below. Also inventory which switches expose their management interface, and from where — a switch you cannot reach from a user subnet is far harder to hit with this bug.

Patch — exact fixed versions

Zyxel released fixed firmware on 22 October 2026 for the ten models "still within their vulnerability support period"; on-market models not listed are stated to be unaffected. Apply the patched build for your exact model:

Model	Affected (≤)	Fixed
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

Source: the Zyxel advisory of 3 November 2026. If your model is end-of-support and not in the table, it will not receive this firmware — treat it as permanently vulnerable and plan replacement.

Can't patch now? Compensating controls

The bug needs network reach to the web-management CGI, so cut that reach:

• Put switch management on a dedicated, isolated management VLAN, and allow the web UI only from a jump host or a short admin ACL — not from user or guest subnets.
• Disable HTTP/HTTPS web management on switches that are administered another way; use the CLI over a controlled channel instead.
• Block inbound access to the switch management ports at the segment boundary for everything except the management source.

None of these fix the flaw; they shrink the set of hosts that can reach it until the firmware is applied.

Hunt for compromise

The published behavior, mapped to MITRE ATT&CK, gives you something to look for. The exploitation is T1190 Exploit Public-Facing Application against the switch CGI; after command execution the exploit pulls a collector script from the attacker's server over TFTP (T1105 Ingress Tool Transfer), which gathers device configuration, network information and hashed root credentials (T1552 Unsecured Credentials, T1005 Data from Local System) and stages the loot in a web-readable folder on the switch for retrieval. Concretely:

• Review switch logs and upstream flow records for unexpected connections initiated by the switch itself — in particular outbound TFTP, and any outbound session from a device that should only ever receive management connections.
• Look for management-interface access from source addresses outside your intended admin range, and for HTTP requests to the CGI with abnormally long or malformed parameter sets.
• Binarly tied this activity to the JITTERLY backdoor and the SIXZUT rootkit and published SHA-256 hashes for both; pull the IOC set from Binarly's advisory and match it against your egress logs. Note that SIXZUT is an LD_PRELOAD userland rootkit built to hide files, processes and connections from on-device tooling — so do not trust the switch's own view of itself; hunt from the network and from upstream logs, not from the box.

Eradicate + verify

A switch that executed attacker commands and leaked its configuration is not clean once patched, and a device carrying an LD_PRELOAD rootkit cannot be trusted to report its own state. For any switch with signs of compromise, flash the fixed firmware from a known-good image rather than updating in place, and treat that as the baseline. Then: rotate the switch's admin and root credentials and any shared secrets (SNMP communities, RADIUS/TACACS keys, management API tokens) that appeared in the stolen configuration; treat the leaked hashed root credentials as crackable and rotate anything reused elsewhere; and review the configuration for unauthorized changes — new admin accounts, altered ACLs, mirrored ports. And if the switch was on a factory-default login, assume the attacker never needed the exploit at all and widen the investigation accordingly. Finally, confirm the fix the way Binarly did: the only proof the patch holds is that the exploit no longer runs against the patched build.

What is not known yet

• Whether the observed GS1900 campaign used CVE-2026-7273, the CVE-2026-107441 bypass, or both; the primary sources leave this open, and GreyNoise's 996-device count was reported under the older CVE.
• The real severity: NVD lists the CVE as "Awaiting Analysis" with no NIST base score, Zyxel says 8.8 adjacent, Binarly says 9.8 reachable over plain HTTP. The vector could shift after analysis.
• Whether the sibling CGIs httprestorecfg.cgi and httpupload.cgi carry the same weak copy routine — a detail reported by a single secondary source, not yet in a primary advisory.
• Whether CISA will add CVE-2026-107441 to the KEV catalog in its own right.

Prove the patch, don't trust it

The failure here was not that a switch had a bug — it was that an organization believed a vulnerability was closed when it was not, because nobody re-ran the attack against the patched firmware. That is the gap an autonomous AI red team is built to close. Zero Hunt runs on an on-premise appliance on its own private models, with a human approving every action that matters: its generative engine identifies the exact product and firmware under test and, through the Exploit Forge, iterates a runnable proof-of-concept against your installed build until it either demonstrably works or demonstrably does not — the same method Binarly used to show the June fix was hollow, run continuously and black-box against your own perimeter rather than once a year. When a device like a GS1900 appears on a segment, a change-triggered campaign can test it within the hour.

Validation and remediation close the loop. Once a finding is proven exploitable, the AI Remediation Advisor ranks it by real exploitability, gives the exact fixed firmware with rollout and rollback notes and a compensating control for the switches you cannot patch yet, and then re-verifies with the same proof that demonstrated the issue — so "we patched it" becomes something you can show, not something you hope. For the data-residency reasons that make on-prem the right model for appliances like these, see our buyer's guide to on-premise pentest platforms; for the older flaw in the same switches, see our note on CVE-2026-7273.