Only the Zyxel switch flaw is in CISA's KEV; the Veeam agent exploitation claim rests on one vendor headline

One flaw has a federal deadline, the other has a headline

CISA's Known Exploited Vulnerabilities catalogue, version 2026.09.21, gained exactly one entry on Monday 21 September: CVE-2026-7273, a stack buffer overflow in Zyxel GS1900 series switches. Its due date is 24 September. That is three calendar days, and it lands on Thursday. The entry is also flagged for forensic triage, which under CISA's new directive means federal agencies must check whether the switch was already compromised, not just patch it.

The other flaw in this week's pairing, CVE-2026-32996 in Veeam Agent for Microsoft Windows, is not in the catalogue. We checked all 1,717 entries in the JSON feed. There are four Veeam entries, all for Backup & Replication, the newest added in October 2024. None is this one.

Those two facts get flattened in the coverage into "Zyxel and Veeam flaws under active exploitation". They are not the same kind of claim, and they should not get the same response.

Here is what the KEV difference does not establish. Absence from KEV does not mean the Veeam flaw is unexploited: CISA adds a CVE only when it has reliable evidence, and it may simply not have that evidence yet. Presence in KEV does not tell you how the Zyxel flaw is being used either. The entry marks known ransomware use as "Unknown". What we know about the attacker and the data taken comes from one threat intelligence company, GreyNoise, not from CISA or Zyxel.

The Zyxel switch flaw: what the record shows

Zyxel's advisory, first released on 16 June 2026 and not revised since, describes a stack buffer overflow in the CGI program of the GS1900 firmware. It "could allow a LAN-based, unauthenticated attacker" to run operating system commands with a crafted HTTP request. Zyxel, the CVE numbering authority for its own products, scores it CVSS 3.1 8.8 (AV:A/AC:L/PR:N/UI:N, high impact on all three). NVD has not added its own score: the record is still "Undergoing Analysis". CISA's enrichment gives the SSVC values that drive the new federal timelines: exploitation active, technical impact total.

The researchers credited are Lei Gu, Jun Cao, Zhiqing Rui, Jingzheng Wu and Tianyue Luo of ISCAS. Ten models are listed, each with a fixed build.

GS1900 models, vulnerable firmware and fixed firmware, from the Zyxel advisory of 16 June 2026 and the Zyxel CNA data in NVD

Model	Vulnerable (and earlier)	Fixed firmware
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

One sentence in the advisory deserves attention. Zyxel says it released patches "for models still within their vulnerability support period", and that on-market products not listed are unaffected. It says nothing about GS1900 variants that are off the market and out of support. If you run an older GS1900 that is not in the table, the advisory does not tell you that it is safe. It tells you that no fix is coming.

The exploitation. GreyNoise published its report on 21 September, the same day as the KEV addition. It says a single actor exploited the flaw "on or about 17 August". The actor ran an exploit written in Python and obfuscated with a 2021 version of the commercial PyArmor tool. It made each switch fetch a collector script over TFTP, then staged configuration, hashed root-level credentials and network information for collection. GreyNoise counts 996 victim switches in 48 countries, and adds that 564 of them still had factory default credentials. That is 56.6 per cent. The recovered script targets GS1900-24 firmware 2.10 to 2.90 and takes options for other builds.

GreyNoise's table puts the United Kingdom eighth, with 33 switches, behind Italy (133), the United States (129), Taiwan (123), France (90), South Korea (69), the Netherlands (66) and the Czech Republic (49). The 48 country counts add up to 996.

"LAN-based" is a label, not a control

Both the advisory and the CVSS vector say the attacker must be on the adjacent network. That is the reassuring part of the Zyxel record, and it is the part the exploitation data undermines.

GreyNoise did not see 996 insiders. It saw one actor, working from infrastructure it had tracked since June, reach close to a thousand switches in 48 countries. GreyNoise does not say how each switch was reached. The plain reading is that the management web interface on these switches was reachable from wherever the actor sat, and for most of them that probably means the internet. That is our inference, not a finding in the report. Either way, the "LAN" in the advisory describes where the vulnerable code listens. It does not describe where your switch's management interface is actually reachable from.

There is a second label worth questioning. CISA's SSVC entry marks the flaw as not automatable. GreyNoise describes a packaged script, with options for different firmware builds, used against 996 devices. We are not second-guessing CISA's formal definition, but defenders should not read "not automatable" as meaning "slow".

Smart managed switches like these are small-office kit, and Zyxel claims more than a million businesses use its networking products, according to BleepingComputer. That kind of estate rarely has a named owner for switch firmware. The 564 devices still on default credentials suggest that for many of these switches, nobody had logged in since installation.

The Veeam flaw: a real escalation with a thin exploitation record

Veeam's KB4852, published on 27 May 2026, lists CVE-2026-32996 as "a vulnerability in Veeam Agent for Microsoft Windows" that "allows for Local Privilege Escalation". It is scored CVSS 4.0 7.3, high (AV:L/AC:L/AT:P/PR:L), and was reported through HackerOne. The KB says it affects Backup & Replication 13.0.1.2067 and all earlier version 13 builds, and that it is fixed from Backup & Replication 13.0.2.29. Veeam's release notes for that build list Veeam Agent for Microsoft Windows 13.0.3.1220.

Arctic Wolf's bulletin of 16 September gives the mechanism at defender depth. The Veeam Endpoint Backup service accepts elevated client sessions over a local gRPC named pipe. It links a cached administrator identity to a session ID that the client supplies, and that ID is not bound to the calling user. Elevated session IDs are written to a log under C:\ProgramData\Veeam\Endpoint that standard users can read. So any logged-on user can take an ID from the log and run commands as SYSTEM. The CNA record classes it as CWE-532, sensitive information written to a log file. Arctic Wolf says technical details and a proof of concept went public on 14 September.

What is thin is the exploitation claim. Arctic Wolf's page carries the headline "UPDATE: Active Exploitation". The page was last modified on 21 September, according to its own metadata. But the body we read describes public proof-of-concept code "increasing the likelihood of exploitation attempts". It does not describe an observed intrusion, a victim count, an actor or a campaign. The Hacker News and SecurityOnline both report active exploitation, and both cite Arctic Wolf as their only source.

The official records have not moved. Veeam's KB4852 was last modified on 17 August, before the proof of concept appeared, and says nothing about exploitation. CISA's SSVC entry in NVD still reads "exploitation: none", dated 28 May. NVD has put the record into "Deferred" status. None of this proves Arctic Wolf wrong. A managed detection provider may see intrusions that it cannot describe publicly. But today, the claim rests on one company's headline.

One more trap, for anyone who relies on a scanner. The CNA's structured product data in the CVE record names "Backup and Replication" versions 13 to 13.0.1 as affected. It does not name the Agent, even though the description does. A tool that matches on product names can mark Backup & Replication servers as vulnerable and miss the Windows endpoints and servers where the vulnerable agent actually runs. Neither source we read says whether standalone agents (installed without a Backup & Replication server) or older agents from version 12 are affected.

What each record establishes, and what it does not. Compiled from the CISA KEV feed, NVD, the Zyxel and Veeam advisories, GreyNoise and Arctic Wolf, all read on 22 September 2026

Claim	What the record establishes	What it does not establish
Zyxel flaw is exploited	CISA KEV entry, 21 Sep; GreyNoise names one actor and 996 victims	Ransomware use (KEV: Unknown); any confirmation from Zyxel, whose advisory is unchanged since 16 Jun
Zyxel data was stolen	GreyNoise: config, hashed root credentials, network info staged for collection	What was done with it afterwards; whether any switch was used to go further into the network
Zyxel attacker is Chinese-speaking	GreyNoise: suspected, from Chinese comments and a UTC+8 working pattern	State direction. Acronis rates a PRC-linked context for the related Red Heron cluster at moderate confidence
Veeam flaw is exploited	Arctic Wolf headline; public PoC since 14 Sep	Any victim, actor or campaign; a KEV entry; any Veeam statement
Veeam flaw puts backups at risk	SYSTEM on any host running the agent	Compromise of the Backup & Replication server or its repositories: not stated

Why backup software sits in a different risk class

The UK reason to care about the Veeam item is not this CVE on its own. A local escalation that needs a foothold first is ordinary. What is different is the product family, and what attackers have done with it before.

The KEV feed contains four Veeam entries. All four are for Backup & Replication, and all four are marked "Known" for use in ransomware campaigns. That is four out of four. Among the 13 Zyxel entries, two are marked Known. One of the Veeam entries, CVE-2023-27532, explains the pattern in its own description. It lets an unauthenticated user inside the backup network "obtain encrypted credentials stored in the configuration database", which "may lead to an attacker gaining access to the backup infrastructure hosts".

That is why a backup server is worse to lose than an ordinary host, for three reasons:

• It holds the keys to everything it protects. To back machines up, a backup server stores credentials for the hypervisors, databases and servers it reaches. Compromise it, and you inherit a map of the estate and the logins to walk it.
• It controls recovery. Ransomware crews destroy or encrypt backups before they encrypt production, so the victim cannot restore and has to negotiate. The NCSC's principles put it directly: ransomware attacks "may seek to frustrate or prevent effective recovery by destroying backups."
• It is trusted everywhere. Backup traffic, service accounts and agents are allowed through by design. Activity that would be alarming from an unknown process looks routine from a backup service.

Now be precise about this flaw. CVE-2026-32996 lives in the agent, a Windows service installed on the protected machines. It is not the Backup & Replication server. On the record, it gives SYSTEM on whatever machine runs the agent. It does not give control of the backup server, its configuration database or its repositories. Anyone who tells you this CVE on its own "compromises your backups" is going further than the sources.

The friendly name still misleads. "Backup agent" sounds like a protective tool. In practice it is a SYSTEM-level service, present on every protected server, with a local control channel. This flaw shows that channel could be driven by any logged-on user. The NCSC has this category in mind: its first principle says destructive requests should be forbidden from customer accounts, "both user and machine identities", and it lists "backup agents" by name. If a SYSTEM-level attacker on a protected host can use that host's backup relationship to delete, expire or overwrite restore points, then a local escalation has become a recovery problem. Whether that is possible depends on how your deployment is built, and the vendor records do not answer it for you.

The fixes were old before anyone was told to hurry

The arithmetic is the uncomfortable part. Zyxel's fix was 62 days old when GreyNoise says exploitation began. The flaw was then exploited for 35 days before it reached KEV. Veeam's fix was 110 days old when the proof of concept went public.

UK organisations certified to Cyber Essentials (Requirements v3.3, April 2026) have to apply updates rated high or critical, or with a CVSS v3 score of 7 or above, within 14 days of release. Both updates qualify: the Zyxel flaw is 8.8, and Veeam rates its CVE high. Those windows closed on 30 June for the Zyxel firmware and 10 June for the Veeam update. An estate that met the Cyber Essentials standard was protected against both flaws weeks before either became news: 48 days before the Zyxel exploitation, and 96 days before the Veeam proof of concept.

The federal three-day clock comes from BOD 26-04, issued on 10 June 2026. For each KEV entry, CISA's own dueDate and forensicTriage fields show which timeline applies. Here they read 24 September and "Yes". CISA's implementation guidance sets target times from the KEV addition: evidence collection within 2 to 24 hours, patching after evidence is secured, triage analysis within 24 to 48 hours, and an escalation decision within 48 to 72 hours. It also says to collect evidence before patching, because patching can destroy it. The directive binds only US federal civilian agencies, but the order of work is sound for anyone.

Who is telling you this, and why

Almost everything known about the attacks comes from security vendors, and that is normal. It is still worth being clear about who is saying what.

GreyNoise sells internet sensor data and blocking. Its report is built on its own sensor network and, by its account, material from the actor's infrastructure. It withholds the main IP address "due to victim sensitivities". It links the actor to Red Heron, a cluster Acronis disclosed on 13 September for exploiting a Gitea flaw, citing a shared command server, malware family and techniques. GreyNoise also says it suspects the actor used a large language model to write its tools, based on code patterns. That is an interesting claim, and GreyNoise itself presents it as suspicion.

Arctic Wolf sells managed detection and response. Its bulletin notes that it detects "multiple stages" of the exploit chain for its own customers. Neither commercial interest makes the findings wrong. It does mean the two claims carry different weight. GreyNoise shows its work: victim counts by country, indicators and a reconstructed script. Arctic Wolf, so far, has published a headline.

What to do, in order

The question that exposes the gap

KEV answers one question: has CISA seen enough evidence to order federal agencies to act? It does not tell you whether your switch management page is reachable from the internet. It cannot tell you whether a SYSTEM-level process on one of your file servers could quietly remove last month's restore points.

So the question for this week is not whether you patched by Thursday. If an attacker had held SYSTEM on one of your protected servers since the proof of concept went public on 14 September, which of your backups could they have deleted, and who would have been alerted?

Key facts