Binarly and GreyNoise findings reported November 9, 2026; Zyxel advisory for CVE-2026-107441 published November 3, 2026; fixed firmware released October 22 to 23, 2026
996 Switches, 48 Countries, One Wrong Diagnosis: the GS1900 Campaign Ran Behind a Patch Built for a Different Flaw
The count is now on the record, and it is worse than the outline the November 5 edition could cite. Reporting published November 9 puts the campaign against Zyxel GS1900 switches at roughly 996 compromised devices across 48 countries, exploited from around August 17, 2026, in activity attributed to a Chinese-speaking actor tracked as Kapibala and linked to the Red Heron campaign. The attackers collected device configurations, hashed root credentials and network information, and GreyNoise found that 564 of the 996 switches still carried their factory-default credentials. The flaw is CVE-2026-107441, an out-of-bounds write in the switches web management program that lets an unauthenticated attacker run operating system commands as root through crafted requests. The detail that reorganizes the incident is the diagnosis. The attacks were first blamed on CVE-2026-7273, which Zyxel patched on June 16 and CISA added to the KEV catalog on September 21. Binarly found the recovered exploit specifically checked for firmware carrying the June fix: the tool was built to run on patched devices, because the vulnerability it used was a different one. Patch 2 was the target, not the cure. Ten GS1900 models on firmware 2.90 Patch 2 or earlier are affected; the fix is the model-specific 2.90 Patch 3 build, released October 22 to 23, with the advisory following on November 3. Scoring carries its own argument: Zyxel and the NVD rate the flaw 8.8 on an adjacent-network vector, while Binarly rates it 9.8 treating the management interface as network reachable, and which number describes your network depends on your own access rules, not on the diagram. Two cautions complete the record. The 996 count comes from Binarly and GreyNoise reporting and Zyxel has not confirmed it, and as of November 5 the actually exploited flaw was still not the one in the KEV catalog; the catalog entry belongs to the June flaw the campaign was misattributed to. The campaign tooling reported by Binarly includes the JITTERLY backdoor and the SIXZUT rootkit, which is why a firmware update alone does not close a switch that was already reached.
Executives
Sit with the sentence this incident proves: a device can be patched, on schedule, against the named vulnerability, and still be compromised through the vulnerability actually in use. Your assurance process almost certainly closes tickets on version numbers, and this campaign was engineered to pass that check, with the exploit verifying the June patch was present. Ask for the GS1900 count in your estate by firmware build, the remediation to Patch 3, and, separately, the compromise review for any switch that ran the vulnerable build during the August window, because the configurations and root credential hashes taken from those devices do not expire when the firmware changes.
CIO / CISO
Run this as two workstreams and do not let the first close the second. Remediation: every GS1900 to its model-specific Patch 3 build, verified by version string after update, with management interfaces restricted to a dedicated segment in the same change. Review: for switches exposed during the campaign window, compare configurations against known-good backups for VLAN, mirroring, account and SNMP changes, look for unexpected outbound connections from the switch, and rotate every credential that appeared in a taken configuration, including credentials reused elsewhere. Note the catalog trap for your compliance reporting: the KEV entry in this story names the wrong CVE, so a KEV-driven trigger alone would have missed the exploited flaw entirely.
Engineers
Work the reachability question first, because it decides which score is yours: enumerate every subnet that can reach TCP 80 or 443 on each switch management address, from the actual access rules, and treat anything broader than an enforced management segment as the 9.8 case. Then hunt with what the device can actually show: embedded switch logging is thin and the exploit needs no login, so build the review on configuration diffs, network telemetry around the switch, and checks for JITTERLY and SIXZUT artifacts on adjacent Linux hosts. Do not accept a June patch record as evidence for this CVE; the vulnerable build is Patch 2 itself.
Everyone (non-IT)
If your workplace or school runs small Zyxel switches, there is nothing for individual users to click or avoid; this one belongs to whoever manages the network equipment. The household version is shorter: network gear ships with a default password, and in this campaign more than half of the compromised devices were still using theirs. Changing the administrator password on your own router and switch, and letting the firmware update when it offers, closes the exact gap counted here.