The patch for your switch had been out for 97 days

Yesterday, 21 September, CISA added one single vulnerability to its catalogue of flaws with confirmed exploitation: CVE-2026-7273, a stack-based buffer overflow in the CGI program of Zyxel GS1900 switch firmware. The flaw itself is unremarkable. What is remarkable are the dates: Zyxel published the advisory and the ten corrected firmware versions on 16 June. Between that day and yesterday there are 97 days. The deadline CISA gives federal agencies to fix it expires on 24 September: three.

What it is and which models it affects

Zyxel's advisory describes it in one sentence: "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." A stack overflow (CWE-121) in the CGI that serves the web admin interface: one crafted HTTP request, no username or password, and execution of operating-system commands on the switch.

The score comes from Zyxel, which is the authority that assigned the CVE: CVSS 3.1 of 8.8, vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Ten models are affected, each with its own version string. If you administer one of them, this table is the whole check:

Nobody found the flaw by exploiting it: the advisory credits the report to five researchers at ISCAS. It was reported, fixed and published. Up to that point, the process worked as it should.

"LAN-based" is not a mitigating factor: it is the requirement

The first letter of the vector is the one most often misread. AV:A means Adjacent Network: the attacker does not come in from the internet, they have to be on the same network. Every time a flaw like this appears, so does the same reassuring reading — "then it does not affect us, the switch is not exposed" — and it is exactly backwards. The vector does not tell you that you are safe: it tells you what the single requirement to attack you is. And on a flat network that requirement is met, from day one, by anything already plugged in: the laptop that fell for a phishing email, the printer down the corridor, the IP camera a third party installed, the visiting salesperson's machine.

Add the rest of the vector: PR:N (no prior privileges), UI:N (nobody has to click anything), AC:L (low complexity). And the target is not just another PC: it is the box everyone else's traffic passes through, the one that can mirror a VLAN to a port, the one that decides what reaches where. That is the difference between a bug and an incident, and the vendor does not set it: what turns a bug into a worm is your network. The real mitigation for an AV:A is not something you buy: it is something you design, and it is called segmentation and controlling who can reach the management plane.

We did the maths: 30 entries this month, median of 5 days

The 97 days invited the question of whether this is normal, so we counted it ourselves and we are publishing the method so it can be argued with. We downloaded CISA's catalogue (version 2026.09.21, 1,717 entries), filtered the 30 added so far in September 2026 and, for each CVE, asked the CVE Program API for its record's publication date. The difference between the two dates is what we measure. Result: median of 5 days, mean of 57.3. When the mean is eleven times the median, the median is not describing anybody.

Because they are two different populations in the same list. 7 of the 30 entered the catalogue on the same day their CVE record went public, or even a day earlier, and five more the next day: there the flaw and the news that it is being exploited arrived together, with no months-long window for anyone to miss. 17 of 30 sit at a week or less. But 12 had had a public record for 30 days or more, and 6 were past 90:

Where the boundary of our count sits, stated plainly: the CVE record's publication date is not the patch date. For Zyxel they coincide, because the vendor advisory and the record are both dated 16 June, which is why the 97 days are 97 days of available patch. For some of those eleven entries they may not coincide, so we are not claiming all of them had a fix from day one: only that their record had been public for that long. The two kernel cases in the table — three came in this month — also show something else — a flaw fixed in the stable branch can take a year to reach your hardware — and that is exactly what keeps the long tail where it is.

The vendor advisory is still June's

At the foot of Zyxel's advisory there is a revision history section. In full, it reads: "2026-6-16: Initial release". One line. Not a word about active exploitation, because the document has not been touched since it was published. We do not raise this as a reproach — almost no vendor rewrites a three-month-old advisory — but because it has a concrete operational consequence: what changed yesterday was not the patch, it was the information. If your process for deciding which firmware is urgent consists of checking the vendor's website, yesterday you saw nothing different from what you saw in June. The signal came from somewhere else.

That somewhere is CISA's catalogue, which is public, downloadable as JSON and asks for no registration. We read it for exactly this reason: a vendor advisory tells you a patch exists; the catalogue tells you somebody is already using the flaw against somebody.

The sentence that decides whether your model is covered

Above the model table, the advisory sets a condition worth reading slowly: "we identified the vulnerable switch firmware versions and released patches for models still within their vulnerability support period". And immediately after: "Please note that on-market products not listed in the table remain unaffected." Together, the two sentences say something quite precise, and it is not "if you are not in the table, you are fine". They say there are patches for models still inside their support period, and that products still on the market which do not appear in the table are unaffected.

The GS1900 is a veteran range with several hardware revisions behind it. The table lists the -24HPv2 and the -48HPv2, but not their earlier non-"v2" versions, which existed and are still mounted in cabinets. For one of those, the advisory gives no answer: it is not in the table and it is not an on-market product either, so the reassuring sentence does not apply to it. We are not saying it is vulnerable — we do not know and we will not claim it; we are saying the advisory does not settle it, and on a task list that is not a "not applicable", it is an open question with a box behind it.

For that case CISA writes the instruction bluntly in the entry's required action: apply the vendor's mitigations "or discontinue use of the product if mitigations are unavailable". Retire the box. It is an awkward sentence to take to a steering committee, and it is the right one: a switch with no firmware to fix it is not fixed by a documented exception, just as the flaw is the vendor's but the exception is yours.

And before you reflash: the entry asks for forensic triage

In the catalogue's JSON, this CVE's entry carries the field "forensicTriage": "Yes" and the required action points to the "Forensics Triage Requirements" of directive BOD 26-04. Meaning: collect before you update. Reflashing a switch means writing an image and rebooting, so the conflict we already wrote about with patching the kernel comes back here, this time with the MAC table, the ARP table and the per-port counters at stake.

Now the honest part: you are not going to take a forensic image off an access-layer managed switch. What you can collect is whatever you were already shipping off the box before any of this — its remote syslog, the flows the firewall or router recorded, who had reach to the management IP, the exported config to compare against — plus a dump of the current configuration and tables before you touch anything. If there is no remote syslog configured, there is nothing to collect: evidence is not gathered on the day of the incident, it is prepared months earlier. It is monitoring's least sellable argument and the only one that matters when the day arrives.

What to check this morning

Five things, in this order, and none of them needs a budget:

1. How many and where. From the inventory, not from memory. Access switches are the asset most often missing from the list, because they were bought with the building work rather than with a project.
2. Each one's version string — the 2.90(AAHL.1)C0 kind — against the advisory's table. The digit that matters is the one before )C0.
3. Who can reach ports 80 and 443 on the management IP. If the answer is "the whole office", that is the genuinely urgent task, and it is today's: it depends on no maintenance window and no vendor.
4. Where the switch's logs end up. If the answer is "on the switch", point 5 happens blind.
5. Update, with a window and with the config exported first. An access switch rebooting means the whole floor off the network for a long minute, so you announce it; and the models absent from the advisory's table get decided now, with a date, not when the next CVE lands.

Our opinion, stated as such: the flaw is Zyxel's, but the 97 days belong to the industry. The switch is the ownerless asset par excellence — no agent, no EDR, no self-updating, absent from every dashboard, and nobody misses it until traffic stops — and that orphanhood is no accident: it is what happens when maintenance belongs to nobody. An available patch that nobody applies is not a vendor failure. It is a decision, taken by omission, every day for three months.

Note on sources

All consulted on 22 September 2026. One: Zyxel's security advisory for GS1900 switches, dated 16 June 2026, source of the flaw description, the full ten-model table with affected version and patch, the sentence about the vulnerability support period, the note about on-market products, the credit to the five ISCAS researchers and the one-line revision history. Two: the CVE-2026-7273 record from the CVE Program, with Zyxel as assigning authority, published on 16 June 2026 at 02:20 UTC; source of the CVSS 3.1 score of 8.8 with its vector, the CWE-121 classification and the list of affected products. Three: CISA's Known Exploited Vulnerabilities catalogue, version 2026.09.21, downloaded as JSON; source of the date added (21 September 2026), the 24 September deadline, the quoted required action, the reference to directive BOD 26-04, the forensic triage field and the fact that ransomware campaign use is listed as unknown. Four, ours: the count of the 30 entries added so far in September 2026 and the gap between each CVE record's publication and its catalogue entry, computed by us by crossing that JSON with the CVE Program API (cveawg.mitre.org/api/cve/<CVE>) and subtracting calendar dates, not timestamps; median 5 days, mean 57.3, 7 entries at zero or negative, 5 more at one day, 17 of 30 within a week, 12 from 30 days up and 6 from 90 up. The catalogue downloads from cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json and Zyxel's advisory sits on its security advisories page, both without registration. What we are not claiming: we have not reproduced the flaw and we do not have a GS1900 in the lab; we do not know who is exploiting this or how, because CISA does not publish that; we do not claim the ten models in the table are the only affected ones in the range, nor that absent models are vulnerable — the advisory simply does not say; and a CVE record's publication date is not the patch date, except when they coincide, as they do here. Our opinion: reading AV:A as a requirement rather than a mitigating factor, that the catalogue's median mixes two different populations, the order of the five checks, and the idea that an available patch left unapplied is a decision.

Cover image: public domain photograph of a communications closet, cropped by us. The text and branding are ours, added on top.