Zyxel GS1900 Zero-Day CVE-2026-107441 Bypassed the June Patch: 996 Switches in 48 Countries Were Hacked Before a Fix Existed
Zyxel has fixed an out-of-bounds write in ten GS1900 switch models that attackers exploited for weeks, even on firmware already patched against the earlier CVE-2026-7273.
What Happened
On 3 November 2026, Zyxel published a security advisory for CVE-2026-107441, an out-of-bounds write in the web management CGI program of its GS1900 series smart-managed switches. Zyxel says an unauthenticated attacker on the LAN can use a crafted HTTP request to potentially run operating-system commands on the switch.
The advisory comes after the fact. Attackers had already been exploiting the bug as a zero-day for weeks, and nearly 1,000 switches were compromised before a fix existed.
How a "Patched" Bug Kept Working
The timeline explains why so many administrators thought they were safe:
- 16 June 2026: Zyxel patched an earlier pre-authentication buffer overflow in the same switch family, CVE-2026-7273.
- Around 17 August: according to researchers, exploitation of GS1900 switches began.
- 21 September: security researchers disclosed a campaign that had compromised 996 devices in 48 countries. They first attributed it to CVE-2026-7273, and CISA added that CVE to its Known Exploited Vulnerabilities catalog the same day.
- 28 September: firmware security researchers investigating infrastructure linked to a campaign known as Red Heron, found an exposed archive containing the attackers' obfuscated Python exploit. They confirmed it worked against all ten firmware releases that had been patched for CVE-2026-7273.
- 29 September: the researchers reported the new flaw to Zyxel.
- 11 October: Zyxel confirmed the issue.
- 22 October: fixed firmware was released.
- 3 November: the public advisory followed.
So devices running the June fix were still exploitable. Administrators who had patched against the known exploited CVE had no reason to suspect they were exposed.
Technical Details
According to the researchers, the exploit corrupts a parameter counter before the firmware validates it. That sidesteps the buffer-overflow checks added in June, and the attacker can then overwrite memory in the CGI process. Zyxel also points to missing validation of HTTP parameter lengths. The October fix limits parameter sizes and validates the parameter count before any data is copied into memory.
Zyxel's advisory does not give a CVSS score. Public vulnerability databases list it as CVSS 3.1 8.8 (High), CWE-787.
Who Was Behind It
Researchers attribute the activity to a suspected Chinese-speaking actor tracked as Kapibala, which is linked to the Red Heron campaign. That campaign was previously reported exploiting a Gitea flaw. Investigators also found a backdoor called JITTERLY and a rootkit called SIXZUT in Red Heron infrastructure.
On compromised switches, the attackers ran a script that collected device configurations, hashed root credentials and network information. That data is useful for mapping the networks behind the switches and pivoting deeper.
Who Is Affected
Zyxel lists ten models. In every case the vulnerable firmware is 2.90(xxxx.2)C0 and earlier, and the patched build is 2.90(xxxx.3)C0:
- GS1900-8: AAHH
- GS1900-8HP: AAHI
- GS1900-10HP: AAZI
- GS1900-16: AAHJ
- GS1900-24: AAHL
- GS1900-24E: AAHK
- GS1900-24EP: ABTO
- GS1900-24HPv2: ABTP
- GS1900-48: AAHN
- GS1900-48HPv2: ABTQ
For example, a GS1900-24 needs 2.90(AAHL.3)C0. Zyxel says unlisted models are not affected.
GS1900 switches are common in small businesses, branch offices, schools and small ISPs. These places often expose management interfaces more widely than they should and rarely monitor switch firmware.
What To Do Now
- Upgrade to the .3 firmware for your model. The June firmware is not enough.
- Treat any GS1900 whose web interface was reachable from untrusted networks since mid-August as potentially compromised. Patching closes the hole but does not remove whatever the attackers already took.
- Rotate credentials on affected switches: admin passwords, SNMP communities and any RADIUS or TACACS shared secrets stored in the configuration. Assume the configuration was copied.
- Restrict the management interface to a dedicated management VLAN or a jump host, and block it at the perimeter.
- Review logs and flows for unexpected outbound connections from switch management IPs, and compare running configurations against known-good backups.
A quick way to find exposed management interfaces on your own ranges, for authorised use only:
nmap -p 80,443 --open -sV 192.0.2.0/24 -oG - | grep -i zyxelWhy It Matters
This case shows the gap between "patched" and "fixed." A KEV listing pointed defenders at the wrong CVE, and the vendor's earlier fix did not stop the real exploit. Organisations that had followed every published recommendation still had compromised switches. It took researchers finding the attackers' own tooling to expose the gap.
For network edge and infrastructure gear, the lesson is to treat a known-exploited device class as suspect even after patching. Keep its management plane off untrusted networks, and verify device integrity rather than assuming the firmware version tells the whole story.
