Vulnerabilities

If you patched your Zyxel GS1900 switches for CVE-2026-7273 after the September exploitation reports, you are not done. On November 3, 2026, Zyxel published an advisory for CVE-2026-107441, an out-of-bounds write in the same CGI program, rated CVSS 8.8. The affected range is the 2.90 .2 build and earlier on all ten GS1900 models, and those .2 builds are exactly the firmware Zyxel shipped in June to fix CVE-2026-7273.

The new flaw was reported by Binarly. The firmware security company says it started from an exploit used in the wild that had been linked to CVE-2026-7273, and found that the patch did not stop it: the exploit runs unchanged against the June firmware because it targets a different bug. Anyone who runs GS1900 switches and treated the June update as the end of the matter should plan another firmware round now.

How it works

The GS1900 is a smart managed switch with a browser-based admin interface. A small web server hands each request (log in, change a VLAN, save the config) to a CGI program, the component that parses the request parameters and acts on them. Both GS1900 flaws of 2026 live in that program, and both are reached by a crafted HTTP request with no login.

CVE-2026-7273 was described as a stack-based buffer overflow: data copied into a fixed-size buffer without a length check. CVE-2026-107441 is an out-of-bounds write (CWE-787), a broader class where the program writes outside the memory it is meant to use, through a bad index or pointer as well as an overlong copy. Binarly says the exploit it analysed targets this second bug, which explains how it survived the June update. A patch that bounds one copy leaves other unchecked writes in the same parser in place, and an exploit built on one of those keeps working on firmware that is marked as fixed.

The CVSS vector is AV:A/AC:L/PR:N/UI:N with high impact on confidentiality, integrity and availability. AV:A means adjacent network: the attacker's request has to reach the switch's management interface from the local network side, which Zyxel phrases as a "LAN-based, unauthenticated attacker". In practice, exposure depends on which networks can reach the switch's management IP on HTTP or HTTPS. If every user VLAN can open the switch's web page, every compromised laptop on those VLANs is a possible attacker. If only a management subnet can, the attacker needs a foothold there first.

Successful exploitation lets the attacker run operating system commands on the switch. A switch sits on every path its ports carry, holds the configuration and credentials for itself, and is rarely watched by endpoint tooling, which makes it a quiet place to persist.

What attackers are doing

Binarly's own announcement describes the starting point as a pre-authentication remote code execution exploit used in the wild against GS1900 switches and linked to CVE-2026-7273, and says the CVE-2026-7273 patch did not stop it. Zyxel's advisory credits Binarly researcher Yegor Vasilenko with reporting CVE-2026-107441, and lists the .2 builds as affected, which matches Binarly's claim from the vendor side.

What is not public yet: there is no count of devices hit through the new bug, no attribution, and no confirmed link between this exploit and the August campaign GreyNoise tracked against CVE-2026-7273, which compromised 996 switches in 48 countries (covered in our earlier post on CVE-2026-7273). As of Zyxel's November 3 advisory, CVE-2026-107441 was not in CISA's Known Exploited Vulnerabilities catalog, according to Rapid7's and OffSeq's vulnerability records. Expect that to change if Binarly's in-the-wild evidence is accepted, and do not wait for it.

Whoever holds this exploit did not need to adapt it when the June firmware rolled out, so a switch that was patched in the September rush but left its management interface reachable from user networks was still exposed until the .3 build arrived.

What to do

Install the .3 build. Zyxel's advisory lists one patched release per model. Every build up to and including .2 is affected.

Zyxel says patches go only to models still inside their vulnerability support period, and that models not listed are not affected. If a GS1900 variant you own is missing from the table, confirm its status with Zyxel rather than assuming it is safe. Check the running version on the switch's status page before and after the upgrade, and keep a note of it per device; the June round showed how easily a fleet ends up on mixed builds.

If you cannot upgrade today. Zyxel lists no workaround. What reduces exposure is making the management interface unreachable from anywhere an attacker might stand. Put the switch's management IP in a dedicated management VLAN, and on the router or firewall in front of it allow TCP 80 and 443 to that address only from named admin hosts. Treat this as a bridge to the upgrade; it does nothing for an attacker already inside the management network.

Check whether a switch was already hit. GS1900 switches keep little useful logging on the box, so look at what surrounds them. In your firewall or NetFlow data, look for HTTP or HTTPS connections to switch management IPs from hosts that are not admin workstations, and for any connection the switch itself starts toward the internet, since a switch has almost no reason to make one. The August campaign against CVE-2026-7273 used the switch's built-in TFTP (Trivial File Transfer Protocol) client to fetch a collector script, so outbound TFTP on UDP 69 from a switch is worth a search too. Compare the running configuration with your last saved copy for new accounts, changed SNMP communities or altered syslog targets.

Clean up after a suspected compromise. Reflash the .3 firmware rather than only upgrading in place, reset the admin password, and rotate anything stored in the config: SNMP communities, RADIUS or TACACS+ secrets and any shared passwords reused on other devices. If the switch was reachable from user VLANs and ran a .2 build or older at any point since August, treat it as suspect.

Why the June patch was not enough

The June advisory described one bug, and the exploit attackers were using relied on another in the same program. Teams that closed their CVE-2026-7273 ticket on seeing a .2 build had no way to know the device was still exploitable. For switches, firewalls and other infrastructure gear that has already been exploited once, two habits limit the damage. Keep management interfaces off user networks permanently, so the next parser bug in the same CGI program cannot be reached from a phished laptop. And keep the ticket open for a few weeks after the first fix, watching the vendor's advisory page and researchers' write-ups for follow-ups on the same component.

Our network penetration testing includes checking which segments can reach switch and router management interfaces, and our safeguarding and hardening work moves those interfaces onto a locked-down management network. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Zyxel security advisory for out-of-bounds write vulnerability in GS1900 series switches, November 3, 2026, Zyxel Community: advisory post for CVE-2026-107441, SecurityOnline: Zyxel GS1900 zero-day CVE-2026-107441 exploited in the wild, bypassing earlier patch, Binarly on X, Rapid7 vulnerability database: CVE-2026-107441, OffSeq Radar: CVE-2026-107441, SecurityWeek: recent Zyxel switch vulnerability exploited by Chinese hackers, Zyxel security advisory for CVE-2026-7273, June 16, 2026.