What happened

Zyxel's June 16 advisory describes CVE-2026-7273 as "a stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware" that "could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request." Ten models are affected, each on firmware 2.90(xxxx.1)C0 and earlier, with 2.90(xxxx.2)C0 as the fix (the four-letter code differs per model; the advisory has the table). Zyxel credits researchers at ISCAS. Its CVSS 3.1 score is 8.8 with an adjacent-network attack vector, which is where "LAN only" comes from.

On September 17 GreyNoise published what it describes as the first documented exploitation in the wild. Its findings:

  • Exploitation began on or about August 17, 2026, two months after the patch.
  • 996 GS1900 switches were compromised across 48 countries; Italy (133), the United States (129) and Taiwan (123) had the most.
  • The attacker collected device configurations, networking information and hashed root credentials.
  • 564 of the victims were still using factory default credentials.
  • The exploit was a Python script obfuscated with PyArmor that pulled a second stage over TFTP.
  • GreyNoise assesses the actor as a suspected Chinese speaker, possibly working in UTC+8, and ties it to a wider campaign against WordPress, Gitea, UniFi OS and other software. That attribution is GreyNoise's assessment; Zyxel and CISA have not named an actor.

CISA added the flaw on September 21 as a "Zyxel GS1900 Series Switches Stack-Based Buffer Overflow Vulnerability." Zyxel's advisory had no exploitation update at the time we read it.

Why it matters if you run public infrastructure

The interesting number is not the CVSS score but the country count. A flaw that needs LAN access does not reach a thousand switches in 48 countries unless their web management interfaces were reachable from wherever the attacker was. The public reports do not break down how each switch was reached, so treat this as an inference: most likely the management pages were exposed directly to the internet, the way small switches often are when someone forwards a port for remote support or plugs the management VLAN into the wrong uplink. The 564 switches on default credentials point the same way: these are devices nobody was actively looking after. A "LAN only" rating describes the vulnerability, not your network.

What to check this week

  1. Find every GS1900 you own, including in branch offices, labs and closets, and check its firmware under the switch's system information page. Anything ending in .1)C0 or earlier is vulnerable.
  2. Upgrade to the .2)C0 build for your model from Zyxel's advisory.
  3. Make sure no switch management interface answers from the internet. Check your public IP ranges from outside for HTTP and HTTPS login pages, not just your firewall rules. Management belongs on a dedicated VLAN reachable only from admin hosts.
  4. Treat exposed, unpatched switches as compromised. Change the admin password (hashed root credentials were taken, and default passwords were common), review the configuration for changes, and compare against GreyNoise's indicators, including outbound TFTP to unfamiliar hosts.
  5. Assume the stolen configurations are useful to the attacker. VLAN layouts, SNMP communities and RADIUS or TACACS secrets in the config should be rotated.

How Attack Surface Scan covers this

Only partially, and it is worth being precise. Zyxel switches are not in the product catalog our vulnerability matching recognizes, so we will not raise a CVE finding or read the firmware version. We monitor hosts by name: the domains you verify, their subdomains and hosts found in certificate transparency logs. If a switch's management page is reachable on a hostname under your domains, it shows up as a web service on 80 or 443 (or another web port we check, see Exposed services), with an alert when it first appears. A switch reachable only by a bare IP address with no DNS name under your domains is outside what we scan, so an external check of your public IP ranges is still needed for this one. We never send exploit traffic. See Vulnerability matching for the products we do match.

Sources