Zyxel's GS1900 Patch Left the Real Zero-Day Wide Open

Zyxel patched the wrong bug. That's the blunt version of what happened to the GS1900 switch line: attackers compromised 996 switches across 48 countries starting around August 17, and the firmware fix Zyxel shipped in June — the one CISA told US federal agencies to install by September 24 — did nothing to stop the exploit actually in use. According to CSO Online, the real flaw, now tracked as CVE-2026-107441, is an out-of-bounds write in the switches' web management interface that lets an unauthenticated attacker run operating system commands. Researchers at Binarly say those commands run as root.

The stolen goods were unglamorous and valuable: device configurations, hashed root credentials, network information. Not ransomware, not defacement — a map of your network and a head start on cracking the keys to it. If you run GS1900s and you installed the June fix and felt virtuous, you were guarding a door the attackers weren't using. Here's what we actually know, what the involved parties claim, and what nobody has answered yet — because with a patch bypass, the difference between the three is where your risk lives.

What is confirmed

Start with the hard floor. GreyNoise, which watches attack traffic through a sensor network, reported on September 21 that attackers pulled data from 996 GS1900 switches around August 17, using a script to collect configurations, hashed root credentials and network information and leaving the loot on the devices for pickup. GreyNoise tied the campaign to CVE-2026-7273, a buffer overflow Zyxel had fixed in June — and on the strength of that, CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities catalog the same day, with a three-day remediation deadline for federal agencies.

Also confirmed: on September 29, Binarly reported a previously unknown flaw to Zyxel and said attackers already had a working exploit for it. Zyxel shipped new firmware — 2.90 Patch 3, with builds ending in .3C0 — on October 22-23 and published its advisory on November 3. Ten models are affected, from the little GS1900-8 up to the GS1900-48 and its PoE siblings; anything on Patch 2 firmware (builds ending in .2C0) or earlier needs the new build. Binarly's technical analysis, which it validated on emulated firmware and real hardware, shows the exploit works against Patch 2 unmodified — the exploit's own supported-firmware list even names the Patch 2 build for the GS1900-24.

What is claimed — and by whom

Now the contested ground, because there's plenty. Severity, for one: Zyxel's CVE entry scores CVE-2026-107441 at 8.8; Binarly scores it 9.8. That gap is not academic nitpicking — it's a fight about preconditions. Zyxel's advisory describes a LAN-based, unauthenticated attacker. Binarly's advisory says:

"an attacker only needs network reachability to the management service" — Binarly's vulnerability advisory, as reported by The Hacker News

If you've spent any time around real networks, you know how often a LAN-based label turns out to be wishful thinking — flat guest networks, missegmented management VLANs, a jump box that isn't. Reachability on paper and reachability in practice are rarely the same thing. According to The Hacker News, Zyxel told Binarly that the June CVE was specifically about the missing parameter-count check, and that it treats the missing size check as the separate flaw now numbered CVE-2026-107441. In other words, the vendor's position is that it fixed the bug it meant to fix. The attackers' position, demonstrated 996 times, is that it doesn't matter.

One more claim worth flagging: Binarly calls it a zero-day and says the exploit GreyNoise described in September matches the one it found. That's a reasonable chain of inference, but note what it rests on — neither GreyNoise nor Binarly says the attacked switches were actually running the June Patch 2 firmware. The exploit demonstrably works on Patch 2. Whether the August victims were patched is unproven.

What nobody is saying

Zyxel's advisory does not state whether CVE-2026-107441 has been exploited — a conspicuous silence given that researchers say a working exploit predates their September 29 report. It lists no workaround for anyone who can't update immediately. And it doesn't answer the two questions that matter most to the 996: does applying Patch 3 evict an attacker who's already in, and what should owners check on a switch that may have been compromised? The advisory is mute on both. This is the part of incident response vendors keep treating as somebody else's problem, and it's why "just patch" is advice, not a plan.

The 140th parameter: why Patch 2 was a speed bump

The mechanics deserve a minute, because they're a masterclass in how patches fail. Per Binarly's analysis, the program handling web requests on the switch stores each request parameter in a fixed area sized for 140 parameters. It never checked the size of any parameter, and before Patch 2 it never checked how many it had stored. The exploit sends a 140th parameter that's too large; it overruns the area and overwrites the program's own parameter counter. The next parameter lands outside the area entirely, letting the attacker swap the function the program is about to call for one that runs the attacker's command.

Patch 2 added a check on the counter. Good instinct, wrong location: the check runs after the oversized parameter has already been copied — at which point the counter holds the attacker's value and the check waves the write through. It's a bouncer who checks IDs after the crowd is inside. In Patch 3, the counter is checked before the copy and the copy itself is size-limited, which Binarly says genuinely closes the hole. Fine. But understand what the June patch cycle actually bought operators: three months of false confidence and a KEV entry pointing at the wrong CVE.

The bill, and who pays it

This is where I get impatient. The commentariat's instinct is to yell "patch faster," but the operators who patched fastest — the federal agencies that met CISA's September 24 deadline, the diligent shops that applied Patch 2 in June — got exactly zero protection from it. Patching was the expensive control here (maintenance windows, change boards, rollout testing across ten models) and isolation was the cheap one. A GS1900's web management interface has no business being reachable from anything but a management VLAN or jump host. That control costs an afternoon of ACL work and would have made this entire campaign — CVE-2026-7273, CVE-2026-107441, take your pick — a non-event. We've watched the same movie with KEV-driven fire drills on edge gear, from Arista's VeloCloud Orchestrator on down: the patch treadmill runs, and the reachable management plane stays reachable.

So what should the board ask? Not "did we patch" — ask these:

1. How many GS1900s do we own, where are they, and who can reach their management interfaces today?
2. Were any of them internet- or broadly LAN-reachable between August and now? If so, who has the hashes that were on them, and have we rotated those credentials?
3. What does the vendor say about post-compromise verification — and if the answer is silence, what's our own hunt plan?
4. What's the refresh cost of replacing managed switches at the edge versus the cost of one incident where an intruder already holds our network map?

My call: apply Patch 3 this week, but don't file this under "patched, done." Treat any GS1900 that was reachable during the campaign as suspect until you've rotated credentials and reviewed its config, and treat management-plane isolation as the control you should have bought years ago. Patching a switch like this is table stakes; verification and segmentation are the meal. The vendor fixed the counter, then the copy. Fix your architecture before someone writes the third CVE.