CRITICAL: Zyxel GS1900 Patch Fails to Stop Unauthenticated Root Exploit

Nothing ruins a patch cycle quite like finding out the patch never worked. That is where owners of Zyxel GS1900 switches find themselves this week. The firmware update everyone rushed to install in September, the one CISA ordered federal agencies to apply against an actively exploited flaw, does not stop the exploit that attackers were actually carrying around. Zyxel has now shipped a second fix, assigned a fresh identifier, CVE-2026-107441, and quietly confirmed that a switch sitting on the "patched" build is still a switch that will run an unauthenticated stranger's commands as root.

If you manage small office networks, branch sites, or the closet full of gear that nobody has logged into since installation day, the GS1900 line is probably somewhere in your inventory. These are inexpensive, fanless, smart managed switches that show up everywhere from dental offices to municipal buildings. That ubiquity is exactly why this matters.

How We Got Here

The backstory runs through the summer. Zyxel published an advisory on June 16 for CVE-2026-7273, a stack-based buffer overflow in the CGI program that powers the GS1900 web management interface. The fix landed in firmware 2.90 Patch 2. Then on September 21, GreyNoise reported that attackers had pulled data off 996 GS1900 switches around August 17, and tied the activity to that CVE. CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities catalog the same day and gave federal agencies until September 24 to patch. We covered that wave here in September, and at the time the advice was simple enough. Install Patch 2 and move on.

The researchers at Binarly did not move on. On September 17 they found the attackers' exploit sitting in an open directory on a server that doubled as command infrastructure for the JITTERLY backdoor. When they pointed that exploit at firmware running Patch 2, it still worked. Binarly tested it against emulated firmware and against real hardware, and the exploit's own list of supported targets includes the Patch 2 build for the GS1900-24. Binarly reported the problem to Zyxel on September 29. Zyxel posted 2.90 Patch 3 on October 23 and published the formal advisory for CVE-2026-107441 on November 3, crediting Yegor Vasilenko and Fernando Mercês of Binarly.

So for roughly five weeks, the attackers held a working exploit against firmware that defenders believed was safe. Let that sit for a second before your next change advisory board meeting.

The Technical Details

The bug itself is a textbook memory corruption problem, and the failed fix is a textbook lesson in why order of operations matters. The CGI binary that handles web requests on the switch stores each incoming request parameter in a fixed region that holds up to 140 entries. It never checked how large each parameter was. Before Patch 2, it also never checked how many parameters it had already stored.

The exploit sends a 140th parameter that is deliberately oversized. That parameter overruns the storage region and overwrites the program's own parameter counter with a value the attacker chooses. The next parameter then lands outside the intended region entirely, which lets the attacker overwrite the function the program is about to call and swap in one that executes their command. Because the web service runs with root privileges, the attacker's command does too.

Patch 2 added a counter check, which sounds reasonable until you look at where it sits. The check runs after the oversized parameter has already been copied. By that point the counter holds whatever the attacker wrote into it, so the check happily approves the next write. It is a bit like installing a deadbolt and then checking whether it is locked only after the burglar has walked through the door. Patch 3 fixes both halves of the problem. It checks the counter before any parameter is copied and limits the size of each copy.

Zyxel's position, according to Binarly, is that CVE-2026-7273 was about the missing counter check and that the missing size check is a separate vulnerability, which is how we ended up with a second CVE. Binarly offers two possible readings. Either Patch 2 was a faulty fix for CVE-2026-7273, or the summer attacks exploited a different flaw from the one CISA listed. Either way, the practical result for defenders is the same.

Zyxel describes the attacker as "LAN-based, unauthenticated," and frames the flaw as one that allows OS command execution through a crafted HTTP request. Binarly puts it more bluntly, saying that "an attacker only needs network reachability to the management service." Those two descriptions are not really in conflict. A switch management interface that is reachable from a flat office network, a compromised workstation, a guest VLAN that was never properly isolated, or the internet itself is reachable enough. The scoring reflects some disagreement too. Binarly rates the flaw at CVSS 9.8, while the NVD entry supplied by Zyxel scores it at 8.8. I would not spend much energy arguing about the decimal. An unauthenticated root command execution bug with a weaponized exploit already in criminal hands deserves to be treated as critical regardless of which number you prefer.

Who Is Affected

All ten GS1900 models covered by the Patch 2 release are affected, and Binarly confirmed the flaw is present in every one of those builds. The GS1900-8 needs to move from 2.90(AAHH.2)C0 or earlier to 2.90(AAHH.3)C0, and the GS1900-8HP from 2.90(AAHI.2)C0 to 2.90(AAHI.3)C0. The GS1900-10HP needs 2.90(AAZI.3)C0, while the GS1900-16 needs 2.90(AAHJ.3)C0. On the 24 port side, the GS1900-24 moves to 2.90(AAHL.3)C0, the GS1900-24E to 2.90(AAHK.3)C0, the GS1900-24EP to 2.90(ABTO.3)C0, and the GS1900-24HPv2 to 2.90(ABTP.3)C0. The 48 port GS1900-48 needs 2.90(AAHN.3)C0 and the GS1900-48HPv2 needs 2.90(ABTQ.3)C0. In plain terms, if the firmware string on your switch ends in ".2)C0" or anything lower, you are vulnerable.

Zyxel notes that patches are provided only for models still within their vulnerability support period, and that on-market products not listed in the advisory are unaffected. If you are running older GS1900 hardware that has aged out of support, the honest answer is that it is time for a replacement conversation.

What Exploitation Looks Like

The activity GreyNoise documented in August was not smash and grab ransomware. Attackers used the exploit to drop a data collection script onto the switches, gather information, and stage it for later pickup. The haul included switch configurations, hashed root credentials, and network layout information. That is reconnaissance, and it is the kind of reconnaissance that makes a later intrusion much easier. Of the 996 switches hit in that wave, 564 were still using factory default credentials, which is a statistic that should make every one of us a little uncomfortable.

GreyNoise links the operators to Red Heron, a Chinese-speaking group tracked by Acronis, or to actors closely related to it. Acronis previously tied the JITTERLY backdoor to Red Heron during an earlier Gitea campaign, which is how the server Binarly found connects back to this story.

It is worth being precise about what we do not know. Neither GreyNoise nor Binarly says the switches attacked in August were running Patch 2, and GreyNoise does not say which firmware those devices had or exactly how the attackers got in. Zyxel's advisory for CVE-2026-107441 does not state whether the new flaw has been exploited, and as of this writing CISA has not added it to the KEV catalog. That said, the exploit was built by attackers, found on attacker infrastructure, and works against Patch 2. I would not wait for an official exploitation flag before acting. Binarly has also said it plans to publish a smaller proof of concept soon, which tends to shorten the window between disclosure and opportunistic scanning considerably.

What To Do Now

The fix is to install 2.90 Patch 3 for your specific model. Zyxel links the release notes and builds from its community forum, and the advisory lists no workaround for switches that cannot be updated yet. If you installed Patch 2 in September and checked the box, uncheck it and go back.

Since Zyxel offers no workaround, network design has to carry the load until every unit is updated. Restrict access to the switch web management interface to a dedicated management VLAN or a small set of administrator jump hosts. If any GS1900 management interface is exposed to the internet, close that today, because there is no good reason for it to be there. Disable HTTP management on ports and VLANs that do not need it, and make sure guest and IoT segments cannot reach switch management addresses at all.

Patching closes the hole, but it does not evict anyone who already walked through it. The advisory does not say whether updating removes access an attacker may already have, and it offers no guidance on what to check if a switch may be compromised. Given that the August campaign harvested hashed root credentials and configurations, treat any GS1900 that was reachable and unpatched during that period as potentially compromised. Rotate administrator credentials after updating, and absolutely replace any factory default passwords. Export and review running configurations for unfamiliar accounts, unexpected SNMP communities, changed syslog or NTP destinations, and mirror port settings you did not create. If you have doubts, a factory reset followed by a clean firmware install and a rebuilt configuration is cheaper than a breach investigation.

On the detection side, look at your firewall and proxy logs for HTTP requests to switch management addresses from hosts that are not administrator workstations. Requests to the switch CGI endpoints carrying an abnormally large number of parameters, or individual parameters of unusual length, are a strong signal worth alerting on. Outbound connections initiated by a switch to anything other than your NTP, syslog, and update servers should never happen, so any switch talking to unfamiliar external addresses deserves immediate attention. If you forward switch logs to a SIEM, watch for unexpected reboots, configuration changes outside maintenance windows, and logins from unusual sources.

The bigger lesson here is uncomfortable but useful. A vendor patch is a claim, not a proof. When a flaw is under active exploitation and researchers have access to the real attacker tooling, it pays to watch for follow-up research in the weeks after you patch, rather than assuming the story ended the moment the update finished installing.

The MSP Angle

Most small business clients have no idea what firmware their switches run, which makes this a natural opening for a network device audit and a managed firmware lifecycle offering that covers switches, access points, and firewalls rather than just endpoints. Pair the patch work with a management plane segmentation project and a credential review, and you turn an emergency fix into a recurring service line.