What happened 

On November 3, 2026, Zyxel published an advisory for an out-of-bounds write vulnerability in the web management interface of its GS1900 series of smart managed switches. The flaw is tracked as CVE-2026-107441. It lets an unauthenticated attacker who can reach the management service send a crafted HTTP request and execute operating system commands. 

The advisory arrived after a messy sequence. GreyNoise had reported in September that one threat actor pulled data from 996 GS1900 switches across 48 countries. The activity was attributed at the time to CVE-2026-7273, a pre-authentication flaw Zyxel had fixed in June with its 2.90 Patch 2 firmware. Then Binarly examined the exploit and found that it still worked against the “fixed” builds. Zyxel agreed it was a separate defect. 

That is why this incident matters beyond the headline number. A patch that organizations applied, and that CISA told federal agencies to apply, did not remove the exposure. 

Quick facts 

Timeline of the Zyxel GS1900 incident 

• June 16, 2026: Zyxel publishes its advisory and Patch 2 firmware for CVE-2026-7273. 

• About August 17: The attacker compromises 996 switches and exfiltrates data. 

• September 17: Binarly researchers find the exploit in an open directory on a server that also served as command infrastructure for a backdoor called JITTERLY. 

• September 21: GreyNoise publishes evidence of exploitation and attributes it to CVE-2026-7273. CISA adds CVE-2026-7273 to its Known Exploited Vulnerabilities catalog the same day, with a September 24 deadline for federal agencies. 

• September 28–29: Binarly confirms the exploit still works on all ten Patch 2 firmware builds and reports it to Zyxel’s PSIRT. 

• October 11: Zyxel confirms a new vulnerability and reserves CVE-2026-107441. 

• October 22: Zyxel releases Patch 3. Some outlets cite October 23 for the community firmware post. 

• November 3: Zyxel and Binarly publish advisories. 

• Next: Binarly has said it will release a smaller proof-of-concept exploit soon, which should raise the urgency for anyone still exposed. 

Read the gap closely. The exploit was in attacker hands and in use roughly six weeks before the vendor confirmed that its first fix was incomplete, and about eleven weeks passed between the first observed compromises and a working fix. 

How the attack worked 

The vulnerable code 

Binarly traced the flaw to dispatcher.cgi, the program that handles web requests on the switch. It stores each request parameter in a fixed-size global structure that holds 140 entries of 1,024 bytes each. A counter variable sits directly after those entries in memory. 

The original code had two weaknesses: it did not check the size of an incoming parameter, and before Patch 2 it did not check how many parameters it had already stored. 

Why Patch 2 failed 

The exploit sends a 140th parameter that is too large. It overruns the end of the storage area and overwrites the counter. The next parameter then lands outside the intended memory, which lets the attacker replace a function pointer so the program runs the attacker’s command. 

Patch 2 added a check on the counter, but the check runs after the oversized parameter has already been copied. By that point the counter contains the attacker’s value, so the check protects nothing. According to Binarly, Zyxel described CVE-2026-7273 as the missing counter check and treats the missing size check as a different flaw. Patch 3 checks the counter before copying and limits the copy size. 

The same parser also appears in httprestorecfg.cgi and httpupload.cgi, which is worth knowing when you review logs and attack surface. 

What the attacker did after getting in 

GreyNoise’s analysis describes a Python exploit protected with the commercial obfuscator PyArmor. After gaining command execution, the attacker pulled a collection script onto each switch (reporting indicates TFTP as the delivery method), gathered the data, and left it to be retrieved. The tooling was built for one purpose: harvest configurations, hashed root credentials and networking details at scale. 

That tells us the objective. This was not noisy disruption. It was reconnaissance and credential theft across a very large number of network devices. 

What we know, and what is still unconfirmed 

In this kind of story, the unknowns matter as much as the facts. Based on what has been published so far: 

1. The 996 figure is tied to CVE-2026-7273. GreyNoise reported it before the new CVE existed. Neither GreyNoise nor Binarly says the compromised switches were running Patch 2, and Zyxel’s advisory does not say whether the new flaw was exploited. The Canadian Centre for Cyber Security notes that open-source reporting indicates exploitation, but the split between the old and new flaw is not established. 

2. Reachability is disputed in wording. Zyxel describes a LAN-based, unauthenticated attacker. Binarly says only network reachability to the management service is required. Plan for the broader reading. 

3. Severity differs. Zyxel scores 8.8; Binarly scores 9.8. Either way, unauthenticated command execution on infrastructure hardware should be treated as urgent. 

4. How attackers reached the switches is not stated. The report does not say whether the targets were exposed to the internet or reached from inside a network. 

5. Attribution is an assessment. GreyNoise links the actor to Red Heron, which Acronis described in an earlier campaign against Gitea servers that used the JITTERLY backdoor. No state sponsorship has been claimed. 

Who is behind it 

GreyNoise tracks the operator as Kapibala and assesses with moderate confidence that it is a Chinese-speaking actor. The same operator was reported to have stolen more than 18,000 government records through WordPress exploitation, and compromised at least 49 WordPress organizations in 29 countries. Over several months the operator was observed exploiting a wide mix of technologies, including Ubiquiti UniFi OS, FlowiseAI, Gitea, Proxmox VE and the Linux DirtyPipe flaw. GreyNoise also noted signs that the actor builds tools with the help of an AI language model, based on code patterns, rapid iteration and comments. 

Two takeaways for defenders. First, this is a broad, opportunistic, multi-technology operator, not a specialist targeting one sector. Second, speed of tooling matters: an actor that can quickly turn a fresh vulnerability into a working collector will outpace slow patch cycles. 

Who and where: victims and geography 

The campaign reached 48 countries. Reporting from Cyber Security News, citing GreyNoise data, says Italy, the United States and Taiwan had the most victims. The full victim list and sector breakdown have not been published, so avoid drawing conclusions about specific industries. 

Affected models and fixed firmware 

Each model below is affected on the listed Patch 2 build and earlier, and fixed on Patch 3: 

Heise reports that patches exist only for models still within Zyxel’s support period. If you have GS1900 hardware outside support, plan replacement and isolate it in the meantime. Always confirm against Zyxel’s advisory before deploying. 

Why this matters for industrial and OT environments 

GS1900 switches are web-managed, lower-cost Layer 2 devices. We cannot say from public reporting how many of the 996 victims were industrial. But this class of switch is common in places where OT and IT blur: small plants, remote sites, utility substations’ corporate-side networks, building automation, warehouse and logistics networks, and test labs. The risk to OT comes from what the switch knows and where it sits. 

1. Configuration files are a network map. A switch configuration typically reveals VLAN design, IP addressing, port descriptions, access lists, management hosts and sometimes SNMP communities or authentication server details. For an attacker planning movement toward a controller network, that is reconnaissance handed over for free. 

2. Credential hashes enable offline attack. Hashed root credentials can be cracked offline without generating a single failed login on your network. Where passwords are weak, reused or default, cracking is trivial. The 564 default-credential victims show how common that gap is. 

3. A compromised switch is a trusted position. Root on a switch means the ability to observe or redirect traffic, mirror ports, alter VLAN membership or open paths that segmentation was meant to block. Segmentation is only as trustworthy as the devices that enforce it. 

4. Management planes are often forgotten. Switches rarely get the monitoring, logging and patch discipline given to servers. Many sit unpatched for years because changes risk downtime, which is exactly the situation OT operators know well. 

5. The patch assumption broke. Vulnerability programs that close a ticket once a vendor fix is applied now face a case where the fix was incomplete. This changes how we verify remediation on network infrastructure. 

Plausible lateral-movement paths (analysis, not confirmed in this campaign) 

• Stolen configs identify OT-facing VLANs and jump hosts, then credentials reused elsewhere are tried against engineering workstations or remote access gateways. 

• A compromised access switch is used as a vantage point to capture unencrypted management or industrial protocol traffic. 

• Attackers alter port or VLAN settings to bridge a segment that was meant to stay isolated. 

These are the reasons to treat any exposed GS1900 as potentially an intrusion point, even if no malicious activity is visible. 

Damage assessment 

What is confirmed: theft of configurations, hashed root credentials and network information from 996 devices. What is not confirmed: persistence on the switches, tampering with traffic, use of stolen data against downstream targets, or any operational disruption. The absence of reports is not proof of absence, particularly because switches offer limited forensic visibility. 

In practical terms, the damage to plan around is exposure of network architecture and administrative credentials, which has a long tail. Stolen information can be used weeks or months later. 

What to do now: a prioritized response plan 

Within 24 hours 

1. Inventory every GS1900. Include devices in branch offices, plants, cabinets and labs. Record model and firmware build. 

2. Remove management exposure. Make sure the web management interface is not reachable from the internet and not reachable from general user or vendor networks. Zyxel lists no workaround, so reachability control is your main interim defense. 

3. Change default credentials on every device immediately. 

4. Apply Patch 3 to all ten affected models, scheduling around plant maintenance windows where needed, and confirm the running build afterward. Do not assume Patch 2 is sufficient. 

Within a week 

1. Rotate privileged credentials and secrets that appear in switch configurations, including SNMP communities, RADIUS or TACACS shared secrets and any local accounts. Assume the configuration was read if the device was reachable. 

2. Review configurations for unauthorized changes: new accounts, altered VLANs, changed ACLs, unexpected syslog or SNMP targets, modified services. 

3. Hunt in logs and network flows for unusual HTTP requests to the management interface, especially to dispatcher.cgi, httprestorecfg.cgi and httpupload.cgi; unexpected outbound TFTP from switches; and management-plane connections from hosts that never normally administer the device. 

4. Consider a clean reflash for devices that were exposed during the August–October window, since update steps do not necessarily remove prior attacker access, and Zyxel’s advisory does not say what to check on a possibly compromised switch. 

Within a month 

1. Move management out of band onto a dedicated, access-controlled management network with a jump host and multi-factor authentication. 

2. Replace unsupported hardware that cannot receive Patch 3. 

3. Add passive OT network monitoring so that changes in traffic patterns, new talkers and new management sessions on infrastructure devices become visible. 

4. Update your vulnerability process: for network devices, verify remediation by testing, not only by checking the version string, and track upstream researcher findings alongside vendor advisories. 

Lessons for CISOs and OT security leaders 

• Patch status is not exposure status. Pair patching with reachability reduction so that an unknown flaw cannot be reached in the first place. 

• Default credentials remain a top-tier risk. More than half of the victims in this campaign still had them. 

• Infrastructure is part of the attack surface. Switches, routers and wireless controllers deserve the same asset visibility and logging as endpoints. 

• Time to patch is only half the clock. Here the more damaging interval was the time between active exploitation and vendor acknowledgment. 

• Segmentation needs verification. Regularly test that the boundaries you designed still exist after configuration changes. 

• Plan for the proof of concept. Public exploit code historically drives a wave of opportunistic scanning, so exposed devices should be fixed before it appears. 

How Shieldworkz can help 

Shieldworkz is an end-to-end industrial OT cybersecurity company. For incidents like this one, teams typically start with a network infrastructure exposure review: finding every managed switch and its firmware, confirming that management interfaces are properly isolated, validating segmentation between IT and OT zones, and building monitoring that flags unexpected management activity. [Add link to the relevant Shieldworkz service page or contact form here.] 

Frequently asked questions 

What is CVE-2026-107441? It is an out-of-bounds write flaw in the web management interface of ten Zyxel GS1900 switch models. An unauthenticated attacker with network reach can send a crafted HTTP request and run operating system commands. 

Is CVE-2026-107441 the same as CVE-2026-7273? No. Zyxel treats them as separate flaws: CVE-2026-7273 covered a missing counter check, while CVE-2026-107441 covers the missing parameter size check. Patch 2 fixed the first but not the second. 

Which Zyxel switches are affected? GS1900-8, 8HP, 10HP, 16, 24, 24E, 24EP, 24HPv2, 48 and 48HPv2 on firmware 2.90 Patch 2 or earlier. 

Is there a workaround? Zyxel’s advisory lists none. Install Patch 3 and restrict who can reach the management interface. 

Do I need to worry if my switch is not on the internet? Yes. Zyxel describes a LAN-based attacker, and any compromised host on a reachable network could attempt exploitation. Internal exposure still matters. 

How many devices were compromised through the new flaw? That is not established. The 996 figure was reported under the earlier CVE, and no source has split it between the two flaws. 

Who is behind the attacks? GreyNoise tracks the operator as Kapibala, assesses it as Chinese-speaking, and links it to Red Heron. No state sponsorship has been claimed. 

Is the vulnerability on CISA’s KEV list? CVE-2026-7273 was added on September 21, 2026. As of reporting on November 4–5, CVE-2026-107441 was not listed. 

Additional resources:

Comprehensive Guide to Network Detection and Response NDR in 2026 here
NERC CIP-015 Internal Network Security Monitoring Readiness Checklist for Electric Utilities here
OT SOC Foundational Guide here
Managed SOC Service here
OT Cyber Threat Intelligence Advisory - Middle East here
NIS2 Directive Achieving NIS2 Compliance Through IEC 62443 here
What Is Removable Media? Risks, Policies, and Industrial OT Security Solutions here
Free Removable Media Policy Template for OT and IT Teams here