The proof of concept for CVE-2026-32996 overflows no stack and corrupts no memory. It opens a text file, looks inside for something shaped like a GUID, presents it over a named pipe and runs whatever you tell it. As SYSTEM. The file is a log belonging to the backup agent, and any user on the machine can read it.
The flaw is in how the Veeam Endpoint Backup service handles elevated sessions over its local gRPC named pipe, \\.\pipe\Veeam\VAW\ServiceConnectionPipe: it caches an elevated administrator principal against a session UID that the client chooses and that is bound neither to the requesting user nor to the connection it came in on. And those UIDs end up written to C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, readable by standard users. The rest is copy and paste.
The researcher who found it published on 14 September and uploaded the executable the next day: you invoke it as CVE-2026-32996.exe "whoami > C:\pwned.txt" and it returns ten lines of console output. Their sentence sums the flaw up better than anyone else's summary: "Session UID can be spoofed, as it is not binded to a identity or connection". NVD classifies it as CWE-532, insertion of sensitive information into a log file, which is precisely what happened.
And now the three things that, with the advisories in front of you, don't match what is being published.
1. The version they tell you to check is not the agent version
Nearly all the coverage repeats the same line: "affects Veeam Agent for Microsoft Windows 13.0.1.2067 and earlier". That number exists, but it is not an agent version: it is a Veeam Backup & Replication build. It does not appear in the official agent build table, and it cannot. Open your agent, compare, and you will find nothing like it — which is exactly where people conclude "doesn't affect me then".
- ▸12 March 2026: server 13.0.1.2067 ships and, the same day, agent 13.0.2.1102. Both vulnerable.
- ▸27 May 2026: server 13.0.2.29 ships and, the same day, agent 13.0.3.1220. Both fixed. That is the number to compare against what you have installed.
- ▸After that: the 13.0.x branch is on agent 13.0.4.1341 (25 August), and the standalone agent —the one no server manages— on 13.1.1.700, from 13 August.
Laid out like that the symmetry shows: every server build has its agent twin, released the same day, under a different numbering. And the blame belongs where it starts, not with whoever copied it: the vendor advisory itself heads the section with "Affected Deployment Type: Veeam Agent for Microsoft Windows" and then immediately writes that the vulnerabilities "affect Veeam Backup & Replication 13.0.1.2067 and all earlier version 13 builds". The advisory induces the mistake in its own first paragraph. The rest was propagation.
2. The laptop's patch is not on the laptop
When the agent is managed —the normal case in any company with a backup server— the supported route to the fixed build is upgrading Veeam Backup & Replication to 13.0.2.29 or later, which brings 13.0.3.1220 along for the agents; you then have to launch that update from the console, it doesn't arrive on its own. Which means: the patch for two hundred user machines hangs off the backup server's change window.
And the backup server is, by a distance, the machine nobody wants to touch: jobs are running, the night window is sacred, and if something goes wrong you lose the safety net on the very day you need it. Result: a local escalation on a laptop inherits the change calendar of the most conservative system in the building. When somebody asks why a patch published in May is still unapplied in September, the answer is almost never "we forgot"; it is this dependency, written down in the technical advisories but in nobody's inventory.
It's the same pattern we wrote about when Acronis documented that its agent "requires local access": backup software lives at maximum privilege on 100% of the estate, precisely because it has to read everything, which makes it the most privileged and most ubiquitous surface you administer. Same as a print server: it runs as SYSTEM and nobody has it on the crown-jewels list. The difference is that the backup one is everywhere.
3. "Active exploitation": what actually holds that phrase up
The "critical" part is quick: the vendor classifies it as High, at 7.3 in CVSS v4.0, vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, reported by Alibaba through HackerOne. The leading L is the one that matters: you have to be on the machine already.
The "active exploitation" part is more interesting, because you can reconstruct the whole thing. On 16 September, managed-detection vendor Arctic Wolf published a bulletin titled "UPDATE: Active Exploitation CVE-2026-32996". The body of that bulletin did not claim real-world exploitation. It said this, and only this: "On September 14, 2026, public technical details and proof-of-concept (PoC) exploit code were released for CVE-2026-32996, increasing the likelihood of exploitation attempts against affected Veeam Agent for Microsoft Windows deployments". That is a probability statement. "Increasing the likelihood of attempts" is not "it is being exploited".
The only thing saying "active exploitation" was the headline. And the headline is what travelled. A week later, on 22 September, coverage had turned it into an observation —outlets writing that researchers "confirmed threat actors are currently exploiting the flaw"— which is exactly what the body did not say. A few days after that, Arctic Wolf pulled the piece: on 28 September 2026 that address does not return the article, it returns the blog listing.
The two sources still standing, the ones you can check today, agree with the body of the bulletin rather than its headline. The vendor advisory mentions exploitation nowhere. And the NVD record carries CISA's own SSVC decision, dated 28 May 2026: exploitation: poc —proof of concept, not active exploitation—, automatable: no and technicalImpact: total. And CISA's Known Exploited Vulnerabilities catalog, version 2026.09.27, 1,728 entries, does not include this CVE. We downloaded it and searched it today.
None of this is an excuse: patch anyway. There is a public exploit, it works, and the privilege it hands over is the highest there is. What you don't want is a headline making the decision, because the same headline that moves you today moves somebody else tomorrow over something that doesn't deserve it, and by the third scare nobody runs. The urgency stands on its own: a public exploit since mid-September, trivial to use, with no vendor-supported mitigation.
Why it doesn't work on every machine
There is a letter in the vector almost nobody comments on: AT:P. In CVSS v4 it means, literally, that the attack is "conditioned on execution conditions that are not under full control of the attacker". And the exploit itself confirms it without meaning to: it first searches for a valid GUID in the log. If an elevated agent session was never opened on that machine, there is no identifier to steal. Which cuts the number of machines where it works first time and cuts nothing at all from the damage on the ones where it does — and an attacker already inside has time to wait for somebody to elevate.
That gives you a prioritisation that isn't the spreadsheet's. The pulled bulletin already recommended prioritising by role —"systems used by administrators, backup operators, help desk personnel, or other privileged users"— and the advice is sound. We add one step, and it is the one that actually decides: don't prioritise by role, prioritise by evidence. Open the log and see whether there are GUIDs in it. Role tells you who should have elevated; the log tells you which machine actually saw an elevation, including the one nobody remembers doing it on. That is how we order estate maintenance when something like this lands: not by alphabetical inventory or org chart, by what is written on disk.
What we would do this week
- 1Inventory the agent version, not the server's. The number that matters is whether you are below
13.0.3.1220. If answering "which agent build is on that laptop?" takes more than five minutes, that is the finding of the day, not the CVE. - 2Look at the log.
C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, on a handful of representative machines. If it contains session GUIDs, there was material to steal on that machine. Thirty seconds, and it tells you whether the problem is theoretical or concrete. - 3Schedule the server before the endpoints. If you are updating two hundred managed agents, the first thing on the calendar is the Veeam Backup & Replication window. Put a date on it this week, or write down that the endpoints remain unpatched; what doesn't work is leaving it implicit.
- 4Leave the detection in place even after patching. The advice doing the rounds —limit interactive access, review local permissions, restrict backup operator and administrator rights, and watch the service, its log files and unexpected child processes launched as SYSTEM— is good, and still holds after the patch. A backup service spawning
cmd.exeis an EDR/MDR rule that should exist with or without this CVE.
What we are not claiming
- ✗We are not saying it isn't being exploited. We are saying no standing primary source claims it, CISA's catalog does not list it, and whoever put it in a headline pulled the piece. No public record does not mean it isn't happening: it means we don't know, and anyone who says they do know has to show where from.
- ✗We have not run the exploit against a system. The mechanics we describe come from the vendor advisory and from the analysis published by whoever found the flaw, not from a lab test of ours.
When this isn't about you
If you don't use Veeam Agent for Windows, this isn't about you and you can close the tab. If you do but you are already on the 13.1 branch of the standalone agent, likewise: you are past the fixed build. And if you are six people with six laptops and the same person installed and updated the agent two weeks ago, this is ten minutes of checking a version, not a project.
We say that knowing which side we get paid on: we sell estate maintenance and managed services, so a post that ends in "inventory your versions" suits us. Hence the counterweight: if you already have a tool that tells you in one click which agent build runs on each machine, you have done the hard part and you need nobody. The company that doesn't is the one that finds the answer by opening machines one at a time — and that one has a problem that isn't this CVE.
Sources (verified on 28 September 2026): flaw description, High severity, 7.3 CVSS v4.0, full vector, credit to Alibaba via HackerOne, the fix starting with 13.0.2.29, and the very sentence that induces the version confusion — Veeam KB4852, "Vulnerabilities Resolved in Veeam Backup & Replication 13.0.2" (published 27 May 2026, last modified 17 Aug 2026); the official agent build table with its dates —13.0.2.1102 on 12 Mar 2026, 13.0.3.1220 on 27 May 2026, 13.1.1.700 on 13 Aug 2026 and 13.0.4.1341 on 25 Aug 2026— and the absence of 13.0.1.2067 as an agent build — Veeam KB2683; server build dates — Veeam KB4738; the original technical analysis, the session-identifier quote and the server/agent mapping — suce, "CVE-2026-32996 Veeam Agent Local Privilege Escalation" (14 Sep 2026, updated 15 Sep 2026), with the repository created on 15 Sep 2026 (date taken from the GitHub API); CWE-532, the score and CISA's SSVC decision (exploitation: poc, automatable: no, technicalImpact: total, 28 May 2026) — the NVD record, queried via API; absence from CISA's KEV catalog (version 2026.09.27, 1,728 entries), JSON downloaded and searched today; the AT:P definition — FIRST's CVSS v4.0 specification. The Arctic Wolf bulletin of 16 Sep 2026 (title, body and the recommendation to prioritise by role) is cited from an archived copy: the original address no longer returns the article.
Do you know which backup agent build runs on each machine?
We inventory agent versions across the whole estate, prioritise by where elevated sessions exist, and schedule the backup server window before touching any endpoint.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN