996 Cheap Managed Switches Got Emptied in One Night. 564 of Them Still Had the Factory Password.

Note: GreyNoise published this research in mid-September 2026 — the report states that as of September 17 it was the first publicly documented in-the-wild exploitation of CVE-2026-7273. CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 21, with a federal remediation deadline of September 24. That makes this four to eight days old as of writing, which is about as fresh as a network-hardware story gets before everyone stops talking about it and the unpatched boxes stay unpatched forever.

There is a device in your building that nobody has logged into since the day it was installed.

It’s probably in a closet, or zip-tied to a piece of plywood behind the register, or sitting on top of the modem under a layer of dust that would tell a forensics person exactly how long it’s been since anyone touched it. It has a web login. The web login has a password. The password is, statistically speaking, 1234.

Last month, somebody wrote a Python script that visited 996 of those boxes across 48 countries in roughly a day and walked out with their configuration files, their network maps, and their hashed root credentials. In 564 of those 996 cases — 57 percent — the device was still using its factory-default login, which means the “hashed root credentials” part was a formality. The attacker already knew the password. Everybody knows that password. It’s printed in a PDF on the manufacturer’s website.

The boxes were Zyxel GS1900 series smart managed switches. The flaw is CVE-2026-7273. The patch has been available since June 16.

If you’ve read this site for a while, you know we’ve spent the last month telling small operators to buy exactly this class of hardware — a cheap managed switch is the single best dollar-per-unit-of-security purchase a small network can make, and we still believe that. We recommended one two weeks ago for exactly the reason you’d expect: flat networks let a single compromised device reach everything.

This story is the other half of that advice, and it’s the half that gets skipped. A managed switch is a computer. It runs firmware. It has a web server on it. The moment you upgrade from a dumb unmanaged switch to a managed one, you’ve added a login-protected Linux box to your network — and you’ve taken on the obligation to patch it, which almost nobody does, because it doesn’t nag you the way Windows does.

The patch shipped June 16. The switches got emptied August 17.

Here’s the timeline, assembled from Zyxel’s own advisory, GreyNoise’s research, and CISA’s catalog entry.

Read that gap again: the fix shipped on June 16, the mass compromise happened on August 17. Sixty-two days. That is not a zero-day story. There was no clever race against an unknown flaw. There was a patch sitting on a vendor download page for two months, and 996 organizations didn’t apply it, because the switch was working fine and nobody’s job description includes “check Zyxel’s advisory page.”

The three-day federal clock is worth noticing as a pattern rather than a detail. CISA gave agencies the same kind of window earlier this month when SonicWall’s SMA1000 remote-access appliances landed on the KEV list a day after disclosure. When the deadline is that short, it’s because exploitation is already underway and the catalog is catching up to attackers, not getting ahead of them. You don’t have a federal deadline. You have the same attacker.

What the bug actually lets someone do to a $100 switch

CVE-2026-7273 is a stack-based buffer overflow in the CGI program of the GS1900 firmware. In Zyxel’s own language: it allows “a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.” SecurityWeek reports it as a CVSS 8.8.

Break that into the parts that matter operationally:

• Unauthenticated. The attacker doesn’t need your password. This is why the 564-default-credentials figure is a re-exploitation problem, not an initial-access one — they got in without credentials and then took the credentials.
• HTTP request. The attack surface is the switch’s web management interface. Not the switching function, not your traffic — the little admin GUI.
• OS commands. Not “crash the switch.” Run code on it, as the device’s own operating system.
• LAN-based. This is the one worth arguing about, and we will, below.

GreyNoise’s technical detail is the part that tells you this wasn’t an opportunistic drive-by. The exploit was delivered by a Python script wrapped in PyArmor, a commercial code-obfuscation product. After GreyNoise deobfuscated it and decompiled the resulting bytecode, the script’s only purpose was exploiting this one CVE — with explicit support for firmware versions 2.10 through 2.90 and command-line options for things like libc base address and global offsets.

Translated: somebody built a proper, version-aware, parameterized exploitation tool for a $100 office switch, paid for commercial obfuscation to protect it, and then used it at scale exactly once that we know of. That is tooling investment. Somebody decided the cheap-switch population was worth building infrastructure for.

”But it says LAN-based — I’m fine, right?”

This is the objection every operator makes, and it deserves a straight answer rather than a scare.

Zyxel’s advisory says LAN-based. That’s accurate as a description of the flaw’s reachability requirement: you have to be able to send an HTTP request to the switch’s management interface. The honest question is how 996 switches in 48 countries became reachable by one attacker in about a day, and the published material doesn’t definitively resolve it. Two explanations are consistent with what’s on the record, and both are common in small-business networks:

1. The management interface was reachable from the internet. This happens more often than anyone wants to admit. A port forward somebody set up in 2021 to “check on things from home” and never removed. UPnP opening a hole nobody requested. A switch that got handed a public IP by an ISP-managed router. A VPS or colo deployment where the “LAN” is a provider network shared with strangers. GreyNoise’s own 2026 State of the Edge report found more than half of remote code execution attempts now originate from IPs never previously observed — the internet-facing edge is under continuous, indiscriminate, cheap-to-run scanning. If your switch GUI answers on a public IP, it will be found.

2. The attacker was already inside the LAN. This actor’s broader campaign — more on it below — was a credential-and-foothold factory. They were compromising WordPress sites, Gitea instances, UniFi controllers, and Proxmox hosts. Every one of those is a machine that sits on the LAN, with a shell, one hop from the switch’s management IP. “LAN-based” is not a moat when the attacker’s business model is acquiring LANs.

The practical takeaway is the same under either explanation, which is convenient: the management plane of your network gear should not be reachable from the internet, and it should not be reachable from your general-purpose LAN either. More on how in a minute.

What they took, and why “just a switch config” is worse than it sounds

The exfiltrated data, per GreyNoise: device configurations, networking information, and hashed root-level credentials.

Operators tend to shrug at this. It’s a switch config. There’s no customer data on a switch. Here’s the actual value of that haul to an attacker:

The configuration is a map. VLAN IDs and names (VLAN30_POS, VLAN40_CAMERAS — people name them helpfully), port assignments, trunk links, IP schemes, management subnets, SNMP community strings, syslog and NTP destinations, RADIUS server addresses, any 802.1X config. That’s a floor plan of your network with the valuable rooms labeled. Reconnaissance that would normally take an intruder days of noisy scanning, handed over in a text file.

Hashed credentials are crackable credentials. Switch admin passwords are chosen by humans, once, in a hurry, and never rotated. Offline cracking against a hash has no lockout, no rate limit, and no alarm. And if that password is reused anywhere — the AP controller, the NVR, the router, a domain account — you didn’t lose a switch password, you lost a password.

Default credentials are a bookmark. For the 564 devices still on factory defaults, the attacker doesn’t need to crack anything. They have a permanent, authenticated way back in that survives the firmware patch, because patching the buffer overflow does nothing about the fact that the admin login is still admin/1234. That is the single most important sentence in this piece for anyone who finds an unpatched GS1900 today: patching is not sufficient. You must also assume the credentials are burned.

Persistence through configuration. With OS command execution on the device, an attacker can do more than read. Port mirroring to a host they control. A DNS server change. A route. A disabled log target. None of those look like malware, because none of them are — they’re supported features, in a config file, on a box no monitoring tool in your building is watching.

The bigger picture: this switch was one aisle in a shopping trip

The Zyxel campaign wasn’t a standalone operation. GreyNoise attributes it to an actor they assess as a suspected Chinese speaker likely operating in UTC+8, based on operational timing and Chinese-language comments in the tooling, and links it to the group Acronis tracks as “Red Heron” via shared C2 domains, malware family, and tradecraft.

The campaign calendar GreyNoise published is the part that should change how a small operator thinks about targeting:

Look at that list from the perspective of “who is this for.” A firewall, a prosumer network controller, an open-source AI workflow tool (FlowiseAI), a blog CMS, a self-hosted Git server, a serverless function platform (Nuclio), a lab information system, a hypervisor, and a small-office switch. Plus a four-year-old Linux kernel bug.

That’s not a target list. That’s an inventory of the stack a small-to-mid-size organization actually runs, including — and this should get your attention if you’ve been standing up local AI tooling this year — two pieces of self-hosted AI/automation infrastructure. If you’ve deployed Flowise or a function runner to try agent workflows on your own metal, you are on the same list as the WordPress sites. We’ve written before about treating self-hosted agent infrastructure as an exposed service rather than an internal toy; this campaign is the receipt.

And the WordPress side of it is the one that undoes the “we’re too small to be a target” reflex permanently. GreyNoise counted 49 victim organizations across 29 countries, described as primarily small business and government. In one intrusion into a Western government organization on July 22, the attacker went from initial exploit at 01:27 UTC to exfiltrating at minimum 18,566 records — including accounts, plaintext passwords, and PII — by 04:09 UTC. Under three hours, start to finish, with time in the middle spent creating a disguised admin account and backdating its registration timestamp to 2025 so a casual audit of the user list would skate right past it.

Nobody chose that organization. A scanner found a vulnerable WordPress plugin. The scale is the point: when acquisition is automated, “too small to be worth targeting” stops being a category. You are worth exactly the cost of one HTTP request.

Am I actually affected? The ten-minute check

Ten models are listed in Zyxel’s advisory. If you own one of these and haven’t touched the firmware since June, assume you’re in scope.

The pattern is simple: the vulnerable builds end in .1)C0, the fixed builds end in .2)C0. Check the last two characters before the closing parenthesis and you have your answer.

”I don’t even know what switch we have” — three ways to find out

Most small shops don’t know what switch they have. Three ways to find out, in order of least effort:

1. Go look at it. The model number is silkscreened on the front bezel and on the label underneath. This is faster than any of the clever options, and while you’re down there you’ll discover the other three devices you forgot about.
2. Check your router’s DHCP lease table or ARP table for a hostname or MAC belonging to Zyxel. Most consumer and prosumer routers list connected devices with a manufacturer name resolved from the MAC prefix.
3. From a machine on the same subnet, arp -a (Windows/macOS/Linux) and look for unfamiliar addresses, then try browsing to them over HTTP. If you get a Zyxel login page, congratulations, you have both an answer and a problem.

The GS1900 GUI shows the running firmware version on the system status page after login. Zyxel’s download center hosts the patched images per model.

The fix, and the four steps after the fix that people skip

Budget 40 minutes for one switch, most of it waiting. Here is where the 40 minutes actually goes, which is also how you decide whether this is a tonight job or a Thursday-after-close job:

Only one line in that table is genuinely outage-bearing, and it is five to ten minutes long. The reason this job sits undone for sixty-two days in a four-person shop is not the 40 minutes. It is that nobody has decided whose 40 minutes it is, and a switch that is working makes a very weak case for itself.

1. Patch the firmware. Download the .2)C0 build for your exact model from Zyxel’s support site, upload it through the web GUI’s firmware upgrade page, let it reboot. Do this during closing or a genuine lull — the switch goes down during the reboot, and if it’s the switch your POS terminals hang off, you will find out in the most expensive possible way. A GS1900 reboot is typically a minute or two of downtime, but plan for ten.

2. Change the admin password — and treat the old one as public. This is the step that separates people who fixed the problem from people who fixed the symptom. If your switch was running vulnerable firmware and was reachable by anyone, its credential hash may have been taken. If it was on factory defaults, there’s no “may.” Set a long, unique, generated password, store it in the password manager, and then go rotate that same password anywhere else it was used. Switch passwords are among the most reused credentials in small business because they get set once during installation by whoever was holding the screwdriver.

3. Get the management interface off the general network. The reason this incident scaled is that the admin GUI was reachable. Reachability is the root cause; the buffer overflow is just this month’s way to abuse it. In rough order of effort:

• Remove any port forward or NAT rule pointing at the switch. Check your router’s port-forwarding table line by line and delete anything you can’t explain. Disable UPnP while you’re there.
• Put the management IP on a management VLAN that only an admin workstation (or a jump host) can reach. This is the same technique we walked through for isolating a print server onto its own segment — you’re just applying it to the switch’s own brain instead of to a device plugged into it.
• Use the switch’s own access controls. The GS1900 line supports restricting management access by source IP. Even a crude “only 192.168.10.5 may log in” rule collapses the attack surface from “everything on the LAN” to “one machine.”
• Turn off the HTTP interface entirely if you never use it, leaving HTTPS or nothing at all. A management interface that isn’t listening cannot be overflowed.

4. Look for what got left behind. With command execution available, assume configuration tampering is possible. Compare the running config against what you expect: unfamiliar VLAN memberships, a port set to mirror traffic, a changed DNS or syslog destination, disabled logging, a new admin account. If you don’t have a known-good config to compare against, this is the moment to export the current one, read it end to end, and save it somewhere as a baseline — which is, not coincidentally, the thing that makes the next incident take twenty minutes instead of a day.

5. If you’re in scope and can’t rule out compromise, rotate broadly. The config told them your network layout and your SNMP strings. If your SNMP community is still public or private, change it. If the switch pointed at a RADIUS server, that’s now a known target. If there were static credentials anywhere in the config, they’re gone.

The device class nobody has a patch process for

Here’s the part that outlives this particular CVE.

Every small business has a category of hardware we’d call install-and-forget: it was configured once, it works, it has no update notification, and it has a web interface. Nobody owns it. It isn’t in any inventory. It doesn’t appear on an asset list because it wasn’t bought as a computer.

The NAS is the outlier, and the reason is instructive: it nags. It has a notification bell and a dashboard you look at because you also use it for files. Everything else on that list is silent by design, and silence reads as “fine.”

Two habits close most of this, and neither costs money:

Write the census. One page, physical or digital: every device on your network with a login, its model, its IP, its firmware version as of today, and the URL of the vendor’s security advisory page. It takes an hour the first time. This campaign hit UniFi controllers in June and Zyxel switches in August — if you have that page, you spend ten minutes on each of those news items instead of ignoring them because you’re not sure whether they apply to you.

Five lines of a real one, for a four-person shop:

The four “unknown” rows are the entire value of the exercise. Every one of them is a device you cannot clear or rule out when a story like this one breaks, and clearing it is one login and one glance at a version string. Do the census once and the next advisory becomes a lookup instead of an argument.

Put a recurring 30 minutes on the calendar, quarterly. Open the census, visit each advisory page, apply what’s pending. Four times a year at half an hour each is two hours annually to stay off a list like this one. We made a similar argument about the monthly patch cadence for the machines that do nag you — this is the same discipline applied to the boxes that don’t.

When this doesn’t apply to you

Some honesty about scope, because security writing has an inflation problem.

If you run unmanaged switches, you are genuinely not affected by this. A dumb $20 five-port switch has no web interface, no firmware you can log into, and no CVE. It also can’t do VLANs, which is a real trade-off — but if your network is one flat segment with five devices and a decent firewall at the edge, an unmanaged switch is a defensible choice and this story isn’t yours. Don’t buy a managed switch out of anxiety about a managed-switch vulnerability.

If your switch is a different brand, don’t relax, but don’t panic-patch at 2pm on a Saturday either. This specific CVE is Zyxel GS1900 only. The behavior — unpatched management plane, default credentials, internet reachability — is universal. Do the census. Skip the emergency.

If your management interface has never been reachable from outside and your LAN has no internet-facing services on it, your risk from this specific flaw is meaningfully lower, and it’s fine to schedule the patch for the next maintenance window rather than tonight. The caveat is that “no internet-facing services” is a stronger claim than most people can actually make. A WordPress site on a box in the office counts. A port-forwarded camera counts. A cloud-managed anything with an outbound tunnel is a longer conversation.

If you’re a one-person shop with a single ISP router and no switch at all, close the tab. This isn’t your problem. The guest network and segmentation basics are a better use of your next free hour.

And if you find a GS1900 on factory-default credentials today, the calculus changes. Patch it now, change the password now, and treat the config as public. That’s not a maintenance window item. That’s a tonight item, and it’s still only 40 minutes.

The real lesson isn’t about Zyxel

A patch existed for 62 days. A commercial-grade exploit tool was built for a $100 box. A single actor with a scanner and a script emptied a thousand of them in about a day, and more than half of them handed over a working login on top of it because nobody ever changed the password that came in the manual.

None of the four failures in that sentence are exotic. They’re the default state of small-business network hardware everywhere, and they will produce the same story with a different vendor’s name in it within a few months — because there is always another CGI binary on another cheap appliance, and the economics of mass scanning mean the cost of finding yours has already been paid by somebody else.

The good news is that the fix list is short, boring, and mostly free: know what you own, change the passwords it shipped with, keep the management plane off the internet and off the general LAN, and spend two hours a year reading vendor advisories for the devices on your own list.

That’s it. That’s the whole defense. It’s not a product, which is probably why nobody sells it to you.

Sources

7 refs

1. GreyNoise, “Open Season on Kapibala: Attacker Steals Over 18,000 Government Records Through WordPress Exploitation” — primary research. Source for the 996 compromised switches across 48 countries, the 564 factory-default figure, the August 17 exploitation date, the PyArmor-obfuscated Python exploit targeting firmware 2.10–2.90, the Red Heron attribution and UTC+8 assessment, the full campaign CVE timeline, the 49 WordPress victim organizations across 29 countries, and the 18,566-record government intrusion timeline.greynoise.io
2. Zyxel security advisory for stack-based buffer overflow in GS1900 series switches (June 16, 2026) — vendor primary. Source for the CVE description (“LAN-based, unauthenticated attacker… OS commands via a crafted HTTP request”), the ten affected models, and the vulnerable-versus-patched firmware build strings in the table above.zyxel.com
3. CISA, “CISA Adds One Known Exploited Vulnerability to Catalog” (September 21, 2026) — source for the KEV listing date and the BOD 26-04 framing, including that the directive binds federal civilian agencies while CISA urges all organizations to prioritize KEV remediation.cisa.gov
4. SecurityWeek, “Recent ZyXEL Switch Vulnerability Exploited by Chinese Hackers” — source for the CVSS 8.8 rating and the small-business-and-government victim profile.securityweek.com
5. BleepingComputer, “CISA orders feds to patch actively exploited Zyxel flaw by Thursday” — source for the September 24 federal remediation deadline and the June 16 patch date, and for context on how widely Zyxel gear is deployed.bleepingcomputer.com
6. Help Net Security, “Attacker compromised nearly 1000 Zyxel switches since August (CVE-2026-7273)” — corroborating source for the exfiltrated data categories (configurations, hashed root credentials, networking information) and the geographic distribution.helpnetsecurity.com
7. CISA Known Exploited Vulnerabilities Catalog — the live list referenced throughout; worth bookmarking if you maintain the device census described above.cisa.gov