Vulnerabilities

CVE-2026-32996 is a local privilege escalation flaw in Veeam Agent for Microsoft Windows, the backup client that runs on endpoints and servers across most Windows environments. It affects version 13.0.1.2067 and every earlier version 13 build. On September 14, 2026, researchers published full technical details and working exploit code, and exploitation attempts in the wild followed within days.

This is a different problem from a ransomware gang threatening to wipe your backups. Here the backup software itself is the hole. Anyone who already has a foothold on a machine running the Veeam Windows agent, even a low-privileged account from a phishing email or an infostealer log, can use this bug to become SYSTEM on that box. Because backup agents run with broad access to files, volumes and often domain credentials by design, a SYSTEM shell on a backup host is a far better position for an attacker than a SYSTEM shell on an ordinary desktop.

How it works

The Veeam Endpoint Backup service, which does the actual backup work, runs as SYSTEM in the background. Other programs on the same machine, including the agent's own console, talk to it through a named pipe: an inter-process communication channel that works like a private, local-only socket between two programs on one computer, with no network involved. This service listens on \.\pipe\Veeam\VAW\ServiceConnectionPipe.

When an administrator opens the agent console or the service needs to run something with elevated rights, it starts a privileged session over that pipe and hands out a session UID, a value meant to say "whoever holds this has already been checked and is allowed to ask for privileged actions." The bug is that this UID is never bound to the specific user, process or connection that received it. It behaves like a bearer token: whoever presents it is trusted, no further check performed.

That would be a narrow issue on its own, since a standard process cannot normally see another session's tokens. What makes it exploitable is where the UID ends up. The service writes every elevated session UID in the clear into C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log, a log file in a folder that standard, non-administrator accounts can read by default. A low-privileged local user opens that log, copies out a still-valid UID from a recent elevated session, and hands it back to the named pipe. The service checks the UID, finds it valid, and runs the user's request as SYSTEM. No password, exploit chain or memory corruption is needed, only a file read and a pipe connection.

What attackers are doing

Public disclosure and a working proof-of-concept exploit went out on September 14, 2026. Arctic Wolf, which tracks the flaw under its own advisory, followed up in the days after with a report of active exploitation attempts against Veeam Agent for Microsoft Windows deployments, and other researchers have separately confirmed that attackers are running the exploit. Neither the number of affected organizations nor the identity of the attackers has been made public, so treat the scale as unknown rather than assume it is small.

What is well understood is the precondition: exploitation needs local access to a Windows endpoint or server already running the affected agent, which almost every organization that runs Veeam has by the dozens or hundreds. That is precisely why this flaw matters even to teams who feel confident about their perimeter. It does not need to be reachable from the internet. It only needs an attacker, or malware, already sitting on one machine with the agent installed.

What to do

Patch the agent

The fix ships in Veeam Backup & Replication 13.0.2.29 or later, which brings every Windows agent up to build 13.0.3.1220. Confirm the installed build from the Veeam Agent for Microsoft Windows console under Help, then About, or by checking the agent's version in Programs and Features. Version 13.0.1.2067 and every earlier version 13 build is exploitable.

If you cannot patch today

Restrict interactive and remote desktop logon rights on machines running the Veeam Windows agent to only the accounts that genuinely need to sign in there, and review who sits in the local Administrators and Backup Operators groups on those hosts. You can also tighten NTFS permissions on C:\ProgramData\Veeam\Endpoint so standard users cannot read Svc.VeeamEndpointBackup.log. Veeam's own advisory for this CVE does not list either step as an official workaround, so test the permissions change on a representative host first in case the service itself needs to write there. Neither replaces the update; both only narrow the window while you roll it out.

Check whether a host was already hit

Look at Svc.VeeamEndpointBackup.log and Windows Security event logs on every machine running the agent. The Veeam Endpoint Backup service has no legitimate reason to spawn cmd.exe, powershell.exe or an unfamiliar binary, so a process creation event (Event ID 4688, with command line auditing turned on) showing that service as the parent is worth investigating immediately. Also correlate logons (Event ID 4624) for standard accounts with SYSTEM-level process creation on the same host shortly afterward. If either pattern turns up, treat the host as compromised: rotate local account and service credentials on it, and look for new local admin accounts or scheduled tasks left behind before trusting that machine's backups again.

Backup software needs the same patch discipline as everything else

Backup agents often sit outside the normal patch cadence because they are not internet-facing and rarely show up in an external scan. This flaw only needs local access, which most endpoints already grant to whoever is logged in, so an agent three versions behind is still a live path to SYSTEM even on a fully isolated network segment. Put backup clients on the same inventory and patch schedule as the servers they protect, not a slower one, since the argument for waiting rarely holds once a component runs with this much reach.

Our safeguarding and hardening work brings backup infrastructure and the agents on every endpoint onto a real patch baseline, checks who can log on to the hosts that carry them, and verifies the fix actually landed rather than assuming a rollout succeeded. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.

---

Sources: Security Affairs, dev.to, Arctic Wolf, Tenable, Veeam KB4852.