Zyxel GS1900 Zero-Day Slipped Past a June Patch and Hit 996 Switches

Attackers broke into 996 Zyxel GS1900 switches across 48 countries using a zero-day that walked right past a June security patch. Zyxel has now shipped a real fix. If your switches still run the June firmware, you are exposed.

What Happened?

In June, Zyxel patched CVE-2026-7273, a buffer overflow in the GS1900 web management interface. Around August 17, a suspected Chinese-speaking group tracked as Kapibala started hitting the switches anyway.

When a threat intelligence firm disclosed the campaign on September 21, everyone blamed the old bug. CISA added it to its Known Exploited Vulnerabilities catalog that same day.

Then a firmware security firm found the attackers’ exploit in an exposed archive on their own servers. The code intentionally checked for the patched firmware. By September 28, researchers had confirmed it worked on all ten patched releases.

How the Bypass Works

The Flaw: CVE-2026-107441

The new flaw is CVE-2026-107441, rated 8.8 on the CVSS scale. It is an out-of-bounds write in the switch’s dispatcher.cgi program.

The June patch added size checks. But attackers corrupt a parameter counter before those checks run. From there, they write to memory and run commands as root. No login needed.

The exploit then pulled a small collector script from attacker servers over TFTP and ran it on the switch.

The Fix and Affected Models

Zyxel confirmed the bug on October 11, shipped fixed firmware on October 22, and published its advisory on November 3. The new builds cap parameter sizes and check the count before copying data.

Ten models are affected: GS1900-8, 8HP, 10HP, 16, 24, 24E, 24EP, 24HPv2, 48, and 48HPv2.

What’s the Impact?

Switches see everything. The attackers grabbed device configurations, hashed root passwords, and network details. That is a map of the internal network.

Worse, 564 of the 996 victims (57%) still used factory default passwords. Patching now closes the hole. It does not undo stolen data.

How to Avoid This

• Update every GS1900 switch to the October 22 firmware. The June build is not enough.
• Pull the web management interface off user networks and the internet. Allow it only from a locked admin network.
• Change default and reused admin passwords, then rotate any secrets stored in switch configs.
• Hunt for signs of compromise: accounts named kapibala or kapibala2, a file at /home/web/tmp/info.txt, and outbound TFTP on port 6969.
• Retest after patching. Run a safe exploit check against the fixed build instead of trusting the version number.

Your Patch Said Fixed. The Attackers Said Otherwise.

A patch is a promise, and promises need proof. Secure.com runs on a simple loop: Attack. Harden. Prove. Repeat.

• The Red Teammate attacks your own exposed edge devices, so a weak fix shows up before a real attacker finds it.
• The SOC Teammate watches for quiet signs on network gear, like odd TFTP traffic or new admin accounts.
• The Cloud and Infrastructure Teammate flags management interfaces reachable from places they should never be.
• Big moves, like pushing firmware or blocking a device, wait for human approval.
• Every test and fix is logged, so you can show auditors proof instead of a ticket that says “done.”

The Bottom Line

This attack did not beat unpatched switches. It beat patched ones. The only fix you can trust is one you have tested like an attacker would.

Frequently Asked Questions