Zyxel closes the CVE-2026-107441 zero-day that its June patch never fixed on GS1900 switches

June 16, 2026. Zyxel ships a fix for CVE-2026-7273, a pre-authentication buffer overflow in the CGI program of its GS1900 switches. September 21, 2026. GreyNoise attributes the compromise of 996 devices across 48 countries to that flaw, and CISA adds it to its KEV catalog. September 28, 2026. Binarly researchers discover the real exploit still worked on all ten patched firmware releases. Why it matters: the June patch closed a door the attackers were not using — the real hole, CVE-2026-107441, stayed open for four more months.

A fix for the wrong flaw

On June 16, 2026, Zyxel shipped firmware addressing CVE-2026-7273, a stack-based buffer overflow in the web-interface CGI program of the GS1900 switches, exploitable by an unauthenticated attacker on the LAN. The case looked closed. It was not.

On September 21, GreyNoise published a campaign run by a Chinese-speaking actor tracked as Kapibala, linked to the Red Heron campaign described by Acronis — the same one that had already exploited a flaw in Gitea and dropped the SIXZUT rootkit. GreyNoise counted 996 compromised devices across 48 countries, with configuration files, hashed root credentials and network information exfiltrated. CISA reacted the same day by adding CVE-2026-7273 to the KEV. Everyone assumed the June fix had simply been skipped by slow-moving administrators.

Binarly proved otherwise. While investigating Red Heron infrastructure tied to the JITTERLY backdoor, its researchers found an open directory hosting an archive called gs1900_bundle.tar.gz. It contained a ready-to-use exploit: a Python 3.10 script, exp.py, obfuscated with PyArmor and shipped with its runtime and bytecode. The exploit targets /cgi-bin/dispatcher.cgi, the web-management CGI on the GS1900.

What the exploit reveals about the real hole

Two details stood out. First, the exploit explicitly checks that the firmware is running the versions patched for CVE-2026-7273 — a sign it was written or updated to bypass exactly that patch. Second, when tested against all ten firmware releases carrying the June fix, it still achieved command execution without authentication.

The mechanism is subtle. The June fix added checks to block the buffer overflow. Attackers got around them by corrupting the parameter counter before it was validated — a technique that overwrites memory and executes commands even on a patched box. This is a separate defect, which Zyxel confirmed on October 11, 2026 as CVE-2026-107441: an out-of-bounds write in the CGI program, combined with missing validation of HTTP parameter lengths.

Binarly reported it to Zyxel on September 29. The vendor released the new firmware on October 22, then its advisory on November 3. The flaw affects all ten models in the GS1900 range.

The timeline that misled everyone

The sequence is worth memorizing, because it explains why nobody reacted in time:

• June 16, 2026 — Zyxel fixes CVE-2026-7273 in firmware 2.90 Patch 2 (XXXX.2)C0).
• August 17, 2026 — GreyNoise begins observing Kapibala exploiting GS1900 devices in the wild.
• September 21, 2026 — GreyNoise discloses the campaign and attributes it to CVE-2026-7273; CISA adds the CVE to the KEV.
• September 28, 2026 — Binarly confirms the exploit bypasses the fix on all ten patched firmware releases.
• September 29 / October 11, 2026 — report to Zyxel, then confirmation of the new CVE CVE-2026-107441.
• October 22, 2026 — release of firmware 2.90 Patch 3 (XXXX.3)C0).
• November 3, 2026 — publication of the official security advisory.

Throughout that window, a diligent administrator who had applied the June patch was still vulnerable — and had no reason to suspect it.

What to do now

Any GS1900 running a 2.90 Patch 2 build (XXXX.2)C0) or earlier is vulnerable to CVE-2026-107441. The fix is in firmware 2.90 Patch 3. Upgrading is the priority, but it is not enough.

A device compromised before the update does not “repair” itself by patching. Attackers exfiltrated configurations and root hashes — enough to establish persistence or move laterally. For each affected switch, you must look for signs of compromise before returning it to production:

# Check the embedded firmware version
show version

# Look for unusual sessions or accounts in the configuration
show running-config | include username

The simple rule: if a switch was exposed on the LAN to an untrusted network — or its management interface was reachable from a segment you do not control — treat it as suspect until proven otherwise.

The lesson: version numbers are not evidence

The episode makes an uncomfortable point for any network team. Security advisories and version numbers help, but they cannot be trusted blindly. Binarly puts it plainly: the only definitive way to know whether software contains a vulnerability is to examine its binary code.

Two details make this worse. First, Binarly believes the exploit was likely generated by an LLM — models give attackers the ability to iterate quickly on patch bypasses. Second, the confusion between CVE-2026-7273 and CVE-2026-107441 cost four months of response, during which the official attribution pointed at an already-fixed flaw.

That is a signal for fleet management: a precise inventory of the firmware actually running, not the declared versions, is the only real line of defense. When a fix is attributed to an active campaign, the right question is not “am I patched?” but “does this patch actually close what the attacker is exploiting?”

Verdict

This is not just another vulnerability in an entry-level switch. It is a failure of the fix → attribution → trust chain: a patch shipped on time, a campaign attributed to the wrong CVE, and a real hole left wide open for months under everyone’s nose.

If you run GS1900 switches, move to firmware 2.90 Patch 3 immediately and run a compromise hunt on every exposed device — the June fix did not protect against what actually happened. For the rest of your fleet, require that every CVE attributed to a campaign be verified against the running binary, not the version number — because trust in advisories is precisely what this attack exploited.

References

• BleepingComputer — Zyxel fixes zero-day exploited to hack nearly 1,000 network switches (November 4, 2026)
• Help Net Security — Patched Zyxel GS1900 switches remained open to in-the-wild exploit (CVE-2026-107441) (November 5, 2026)
• Binarly — Zyxel GS1900 RCE CVE-2026-107441
• Zyxel — Security advisory for out-of-bounds write vulnerability in GS1900 series switches (November 3, 2026)
• Zyxel — Security advisory for stack-based buffer overflow vulnerability in GS1900 series switches (June 16, 2026)