Zyxel GS1900 CVE-2026-107441: June Firmware Patch Still Vulnerable, Update to .3

What the flaw is​

The vulnerability is tracked as CVE-2026-107441. It is an out-of-bounds write in the switches' web management interface. An unauthenticated attacker with network access can use specially crafted HTTP requests to execute operating system commands.

Zyxel's own advisory wording describes the attacker as being on the local network. Its CVE record says an unauthenticated adjacent attacker could potentially execute OS commands via a crafted HTTP request. Zyxel rates it CVSS 8.8.

Binarly, which found the flaw, reads it differently. Binarly says the bug lives in global memory, not on the stack, and works over normal HTTP from any network that can reach the switch. It therefore rates the flaw higher than Zyxel's 8.8. One aggregator reports Binarly's severity score as 9.8, but I could not confirm that figure against Binarly's advisory text. Treat the severity dispute as unresolved. Either way, any switch whose management interface is reachable by an untrusted party should be treated as at risk.

Affected models and fixed firmware​

Ten GS1900 models are affected. Binarly's advisory lists the vulnerable .2 firmware releases, and Zyxel's advisory lists the .3 releases as patched. In every case, Binarly lists the vulnerable build as the .2 release.

A switch on the June .2 release is still vulnerable. Models outside this table are not listed as affected.

Why the June patch did not cover it​

On June 16, 2026, Zyxel published its CVE-2026-7273 advisory and fixed releases. That flaw was a stack-based buffer overflow in the same switch family. Zyxel's advisory index lists the June CVE and the November CVE as separate entries.

BleepingComputer's account of Binarly's analysis is that the June update added checks against a buffer overflow. Attackers could bypass those checks by corrupting a parameter counter before it was validated. Zyxel treats the result as a separate flaw because the exploit also abused missing validation of HTTP parameter lengths.

Zyxel has also told Binarly that CVE-2026-7273 covered a missing counter check, even though its advisory described a stack overflow. That is an odd mismatch between a vendor's description and its own explanation. It is also a reminder that "patched" only means the specific bug in the advisory was fixed.

The October 22 firmware addresses this by limiting parameter sizes and validating the parameter count before data is copied into memory.

The attack campaign and a caveat on the numbers​

GreyNoise reported that a threat actor exploited CVE-2026-7273 against 996 Zyxel GS1900 switches across 48 countries. GreyNoise dates the activity to around August 17. It says the actor stole configurations, hashed root credentials and networking information. GreyNoise links the actor to Acronis's "Red Heron" reporting based on shared command-and-control infrastructure, malware family and other tactics. It calls the actor a suspected Chinese speaker.

GreyNoise also described the exploit script as heavily obfuscated with PyArmor. It said the script explicitly targeted GS1900-24 firmware from 2.10 to 2.90, with command-line options for other firmware in scope.

GreyNoise attributed the attacks to CVE-2026-7273, the older CVE. Its 996-victim count was therefore reported under that label. The evidence I reviewed does not show that every one of those 996 switches was compromised through CVE-2026-107441.

The sequence of events, per Binarly's timeline:

• September 21: CISA adds CVE-2026-7273 to the KEV catalog. The KEV entry covers the older flaw, not the new one.
• September 28: Binarly confirms that all ten fixed releases remain affected.
• September 29: Zyxel PSIRT is notified.
• October 11: Zyxel confirms the new vulnerability and reserves CVE-2026-107441.
• October 22: Zyxel releases the fix.
• November 3: Zyxel publishes its advisory and Binarly discloses publicly.

BleepingComputer notes it remains unclear whether the exploit was deliberately built to bypass the June patch or simply hit a related weakness that patch missed. Binarly's reporting is more direct. The exploit's configuration lists addresses for the patched GS1900-24 firmware, and Binarly says the latest firmware released as the CVE-2026-7273 fix is vulnerable to the same exploit, which works without changes.

Binarly found the exploit while investigating Red Heron infrastructure tied to the JITTERLY backdoor and the SIXZUT rootkit. JITTERLY is a Linux backdoor with more than 30 commands. It hides a rootkit called SIXZUT inside itself, which can conceal files, processes and network links.

What administrators should do​

1. Inventory every GS1900 switch. Record the exact model and running firmware. Don't assume that being on the June release means you are protected.
2. Compare against the table above. Any .2 build, or anything older, needs the matching .3 release.
3. Install the fixed firmware from Zyxel's download channel for that model.
4. Limit who can reach the web management interface. Zyxel's advisory, as far as I could verify, names no workaround, so this is general hardening and not a vendor-specified fix. Given the unauthenticated nature of the bug, keeping management on a dedicated VLAN is sensible, but it does not replace patching.
5. Assume prior exposure is possible. The reported attacks stole configurations and hashed root credentials. If a switch was reachable and unpatched, consider rotating administrator credentials and reviewing configurations. This is my inference from the reported theft, not Zyxel guidance.

Why this matters​

Switches sit at the core of a network, and they are rarely monitored as closely as servers or PCs. A compromised one can expose configuration details, credentials and the network layout. For Windows-centric shops, that includes VLAN design and the paths to domain controllers and file servers.

The wider lesson is about patch verification. A CVE entry in the CISA KEV catalog can leave defenders thinking the job is done once the named patch is installed. Here, the fixed builds were still exploitable. When a vendor's fix is reported as bypassed, check whether the vendor has shipped a newer release.

At the time of writing, I found no public workaround in Zyxel's materials. The practical answer is to update to the .3 firmware.