Zyxel GS1900 CVE-2026-7273: Unauthenticated RCE, Now Exploited in the Wild

On 21 September 2026 CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities catalogue, with a federal patch deadline of 24 September. The flaw is a stack-based buffer overflow in the web-management CGI of Zyxel's GS1900 series — smart-managed switches sold by the hundreds of thousands into small and mid-sized networks. A LAN-adjacent, unauthenticated attacker sends one crafted HTTP request and executes operating-system commands on the switch.

Zyxel patched this in June. The advisory is dated 16 June 2026. Three months later, attackers are using it and CISA is putting a clock on it. That gap — patch published in summer, exploitation confirmed in autumn — is the entire story, and it is a story that repeats on embedded network gear every year.

What CVE-2026-7273 actually is

Zyxel describes it plainly: "a stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request." It carries a CVSS 3.1 base score of 8.8.

Decompose that sentence and every clause is bad news:

• CGI program — the vulnerable code is the switch's HTTP management interface, the same web UI an administrator logs into. It is reachable by anyone who can open a TCP session to the management IP.
• Stack-based buffer overflow — a classic memory-corruption primitive. On an embedded MIPS/ARM switch with no modern exploit mitigations (no meaningful ASLR, often no stack canaries, frequently running the web server as root), a stack overflow in the request parser is a direct route to code execution.
• Unauthenticated — no login, no session, no credential. The overflow triggers before authentication.
• Execute OS commands — not a crash, not a config change. Shell-level control of the device.

Researchers have not published proof-of-concept code, and CISA's addition notes active exploitation without one. That combination is worth pausing on: someone reverse-engineered the June patch, built a working exploit, and is using it privately while the rest of the industry has no public PoC to test detections against. The exploitation is ahead of the public disclosure curve, not behind it.

"LAN-based" is not the reassurance it sounds like

The CVSS vector marks this as adjacent (AV:A), not network-remote, and the reflex reaction is relief: the attacker has to already be on my LAN, so I'm fine behind the firewall. That reasoning is exactly the gap attackers monetise, and it is why a raw CVSS score tells you almost nothing about your actual exposure.

"LAN-based" describes the attacker's position, and in 2026 that position is cheap. Consider who is already sitting on the same broadcast domain or an adjacent VLAN as your access switches:

• A compromised laptop that clicked the wrong invoice.
• An IP camera, a badge reader, a VoIP phone, a printer — the unmanaged IoT population that lives on switch ports and is a permanent Mirai reservoir.
• A "guest" or "IoT" VLAN that was supposed to be isolated but shares the switch's management subnet because someone was in a hurry during deployment.
• The switch's own web UI, deliberately exposed for remote administration. During the 2023 Zyxel firewall campaign, Rapid7 counted roughly 42,000 internet-exposed Zyxel web interfaces — administrators expose these boxes constantly.

So the real question CVE-2026-7273 asks is not "is my switch on the internet?" It is: can anything I do not fully trust reach the switch's management CGI? That is a network-segmentation question, and most organisations cannot answer it with evidence. They have a VLAN diagram that describes intent. Whether the running configuration on every switch actually enforces that diagram — whether the management plane is truly unreachable from the camera VLAN — is a different fact, and it is only knowable by testing it.

"We're patched on the servers." "Did anyone patch the switches?" "…the switches have a web interface?"

That third line is where most incident calls stall. Switches are infrastructure; infrastructure is invisible until it is the pivot.

Why rooting a switch is worse than rooting a server

A server is a destination. A switch is the fabric everything else rides on, and code execution on it hands the attacker capabilities that no host-based control can see:

Capability after switch RCE	What the attacker does with it
Port mirroring / SPAN	Silently copies every packet crossing the switch to a port they control — credentials, tokens, unencrypted internal traffic.
VLAN reconfiguration	Collapses the segmentation you built. The "isolated" OT or card-data VLAN becomes routable to the attacker.
ACL / static route edits	Redirects or man-in-the-middles traffic; disables the very filtering meant to contain them.
Firmware-level persistence	Survives reboots and lives below every EDR agent, which run on hosts, not on the switch.

There is no endpoint agent on a GS1900. There is no EDR telemetry, no easy memory capture, no straightforward forensic image. The device that would normally be part of your monitoring becomes a blind spot the moment it is owned — and because it sees all the traffic, it is the ideal place from which to watch and to pivot.

CVE-2026-7273 patched in June, exploited in September: the embedded-gear pattern

None of this is novel, and that is the point. Zyxel hardware has been a botnet staple for years. CVE-2023-28771, an unauthenticated command-injection flaw in Zyxel firewalls, was mass-exploited by a Mirai variant within weeks of disclosure and folded thousands of devices into a DDoS botnet. Embedded network devices are attractive precisely because they are rarely patched: no auto-update, a manual firmware flash that risks bricking a switch nobody wants to touch during business hours, and an install base that includes units racked years ago and forgotten.

The three-month lag between Zyxel's June advisory and September's confirmed exploitation is the defenders' patch window, and it closed while most of these switches sat on their shipping firmware. This is also the pattern CISA's BOD 26-04 — the risk-based directive that replaced the flat 14-day KEV rule earlier in 2026 — is built to compress: it tiers remediation urgency by exploitation evidence rather than by CVSS alone, and an actively exploited, unauthenticated RCE on network infrastructure lands in the fastest tier. The reason the directive had to change is the reason this CVE matters: a 8.8 that nobody was exploiting in June is a 8.8 that is now, and the score never moved.

Remediation

A complete, defensive runbook for CVE-2026-7273. Do the exposure check and the compromise hunt even if you patch immediately — a switch running vulnerable firmware for three months should be treated as possibly-already-touched, not merely as needing an update.

1. Am I affected?

Inventory every Zyxel GS1900 switch and read its running firmware from the web UI (System → General Setup shows the firmware string) or, if you have serial/console access, from the boot banner. Compare against the affected line below. Any GS1900 model on firmware 2.90(...).1C0 or earlier is vulnerable. If you cannot enumerate your switches, that is finding number one — an unmanaged switch is exactly the device that stays on shipping firmware.

Externally, confirm no GS1900 management interface answers from an untrusted network. From outside the management VLAN:

# HTTP/HTTPS management should NOT respond from a user/IoT/guest segment
curl -sk --max-time 5 https://<switch-mgmt-ip>/ -o /dev/null -w "%{http_code}\n"
# Treat any 200/302/401 reachable from an untrusted segment as an exposure to fix,
# independent of the patch.

2. Patch — exact fixed versions

Zyxel's fixed firmware, per model (from the 16 June 2026 advisory):

Model	Affected (and earlier)	Fixed
GS1900-8	2.90(AAHH.1)C0	2.90(AAHH.2)C0
GS1900-8HP	2.90(AAHI.1)C0	2.90(AAHI.2)C0
GS1900-10HP	2.90(AAZI.1)C0	2.90(AAZI.2)C0
GS1900-16	2.90(AAHJ.1)C0	2.90(AAHJ.2)C0
GS1900-24	2.90(AAHL.1)C0	2.90(AAHL.2)C0
GS1900-24E	2.90(AAHK.1)C0	2.90(AAHK.2)C0
GS1900-24EP	2.90(ABTO.1)C0	2.90(ABTO.2)C0
GS1900-24HPv2	2.90(ABTP.1)C0	2.90(ABTP.2)C0
GS1900-48	2.90(AAHN.1)C0	2.90(AAHN.2)C0
GS1900-48HPv2	2.90(ABTQ.1)C0	2.90(ABTQ.2)C0

Verify the firmware string after flashing; a failed or half-applied update on an embedded switch fails silent.

3. Can't patch now? Compensating controls

The overflow is in the web-management CGI, so the whole exposure surface is reachability of the management plane:

• Restrict management access to a dedicated, isolated management VLAN with an ACL that permits only known administrator hosts. This is the single most effective control, and it is a control you should be able to keep even after patching.
• Disable HTTP/HTTPS web management where the switch can be administered by other means, or bind it to the management interface only.
• Block the switch management IPs from IoT, guest, printer/camera, and general user VLANs at the layer-3 boundary. The attacker needs to reach the CGI; deny the path.
• Rate-limit / drop anomalous HTTP to switch management IPs at an upstream firewall if the switch must remain web-managed.

4. Hunt for compromise

There is no on-switch EDR, so hunt from the network and from the switch's own state:

• Configuration drift — diff each switch's running config against a known-good baseline. Look for new/unexpected mirroring (SPAN) sessions, changed VLAN membership or trunk config, new static routes, altered management ACLs, and new local accounts. A rogue SPAN session is the clearest tell that someone is exfiltrating traffic (ATT&CK T1200 hardware additions context; T1040 network sniffing).
• Egress from switch management IPs — a switch should almost never initiate outbound connections to the internet. Any beacon, any connection to a never-seen ASN, any DNS burst originating from a management IP is high-signal (ATT&CK T1071 C2, T1571 non-standard port).
• Unexpected reboots / firmware anomalies — memory-corruption exploits are unreliable and often crash the service; a switch with unexplained reboots around the exploitation window deserves scrutiny.
• Botnet behaviour — sustained outbound scanning or SYN floods sourced from the switch's IP indicate it has been recruited (the Zyxel/Mirai pattern; ATT&CK T1498 network DoS from the botnet's perspective).

Map the intrusion as T1190 (exploit public-facing / reachable application) → OS command execution → T1542/firmware persistence and T1040 traffic capture.

5. Eradicate + verify

• Patch first, then treat the device as untrusted until proven clean.
• Factory-reset and re-flash any switch showing indicators — on embedded gear a patch does not remove an implant, and firmware-level persistence can survive a simple upgrade. Reset to defaults, flash the fixed firmware, and rebuild the configuration from your baseline, not from the switch's current running config (which the attacker may have edited).
• Rotate everything the switch could have seen or held: local switch admin credentials, SNMP community strings, RADIUS/TACACS shared secrets configured on it, and — because a rogue SPAN session may have captured them — credentials and tokens that transited it in cleartext.
• Re-verify segmentation after the rebuild: confirm the management plane is unreachable from every untrusted VLAN, and confirm no mirroring session or route you did not create remains.

Reachability is the whole question — and it is testable

Everything above reduces to one operational question the CVSS score cannot answer for you: from where an attacker actually lands — a phished laptop, a Mirai camera, a guest VLAN — can they reach the management CGI of your GS1900 on your running configuration? A vulnerability scanner tells you the firmware version. It does not tell you whether the path exists. Only exercising the path does.

This is the operational gap Zero Hunt's AI Generative Pentest pillar is built to close. The 10-agent swarm does not stop at fingerprinting a firmware string; the Post-Exploit and Pivot agents take a realistic low-privilege foothold — the exact camera-VLAN or compromised-endpoint position CVE-2026-7273 assumes — and prove whether the switch's management plane is reachable from there, on your real topology, not on a diagram. The Exploit agent writes a per-target probe with a local LLM rather than pulling a public PoC that, for this CVE, does not yet exist to pull. Every step is backtested in the AI Gym against the Vulhub CVE corpus before it runs in production, and every finding is ECDSA-signed at write time, so the output is "here is the segment this switch was reachable from, and here is the evidence," not a deferred 8.8 on a spreadsheet. A change-triggered campaign fires within the hour when a new management interface appears on the perimeter — which is precisely how an unmanaged switch that "wasn't supposed to be reachable" gets caught before a botnet's scanner finds it first.

And because a rooted switch owns its own logs — it can clear its event buffer and rewrite its config as easily as an attacker can enable a SPAN session — the post-exploitation activity is read most reliably off the wire. Zero Hunt's AI Traffic Analysis model, with four inference heads running on the appliance GPU at 2.7+ Gbit/s, flags the beacon to a never-seen ASN, the anomalous egress from an IP that should only switch traffic, and the outbound scan of a freshly recruited botnet node — while it is happening, not in the next morning's SIEM digest, and from a vantage point the compromised switch cannot edit.

The switch is the network. When it can be taken with a single unauthenticated request, "we patched the servers" is not an answer. Knowing — with evidence — what can reach it is.