As reported by SecurityAffairs, a public proof-of-concept exploit for CVE-2026-32996 — a local privilege escalation vulnerability in Veeam Agent for Microsoft Windows — was published on September 14, 2026, materially increasing the probability of in-the-wild exploitation. The flaw allows any authenticated local user to escalate from a low-privilege account to NT AUTHORITY\SYSTEM, effectively granting full control of the machine.

Security Impact: As reported by SecurityAffairs, a public proof-of-concept exploit for CVE-2026-32996 — a local privilege escalation vulnerability in Veeam Agent for Microsoft Windows — was published on September 14, 2026, materially increasing the probability of in-the-wild exploitation.

Vulnerability Summary

FieldDetail
CVE IDCVE-2026-32996
SeverityCritical (local privilege escalation to SYSTEM)
Affected ProductVeeam Agent for Microsoft Windows
Affected VersionsVersion 13.x through 13.0.1.2067 (all earlier v13 builds)
Attack VectorLocal — requires authenticated low-privilege access
ImpactFull SYSTEM-level code execution
PoC AvailableYes — public on GitHub since September 14, 2026
Active ExploitationNot yet confirmed, but likelihood is high given public PoC
Patch StatusCheck vendor advisory — update to latest available build immediately

Why This Matters More Than a Typical LPE

Local privilege escalation bugs are often deprioritized by defenders because they require an initial foothold. That calculus shifts dramatically in three scenarios — all of which are common in enterprise environments:
Vulnerability Summary
Multi-user endpoints: Any standard user on a shared workstation (kiosks, jump hosts, RDS servers, lab machines) can pivot to SYSTEM and access other users' sessions, credentials, and data.
Post-compromise lateral movement: Attackers who land on a Veeam-protected machine via phishing, malware, or any initial access vector can use this LPE to entrench themselves, disable backups, and prepare for ransomware deployment.
Backup infrastructure as a target: Veeam agents run on production systems. SYSTEM-level access on a backup-protected host can be leveraged to tamper with backup configurations, delete restore points, or exfiltrate backup metadata — directly undermining recovery operations.
The root cause is a session-binding failure: the Veeam Endpoint Backup service caches elevated administrator principals against client-controlled session UIDs transmitted over the local gRPC named pipe \\.\pipe\Veeam\VAW\ServiceConnectionPipe, without verifying that the UID corresponds to the requesting user. Worse, those UIDs are logged to C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log — a file readable by any standard user. The attack is trivially reproducible: read the log, extract a valid UID, replay it.

The Design Lesson

This is a textbook example of confused deputy combined with improper session binding. The service acts on behalf of callers using a session identifier that it neither validates nor cryptographically ties to the caller's identity. Any security-aware software design that uses session tokens over local IPC must enforce mutual authentication — bind the session to the caller's SID, process token, or pipe impersonation context. Logging sensitive session artifacts to world-readable files compounds the error and eliminates any barrier to exploitation.

Who Is Most at Risk

  • RDS / Citrix farms where Veeam Agent is installed on multi-session hosts
  • Shared developer or analyst workstations with Veeam Agent for endpoint backup
  • Jump boxes and bastion hosts that may have Veeam agents installed for local backup
  • Any environment where standard users coexist with Veeam Agent v13.x

Shield53 Recommendations

Immediate Actions

  • Patch now. Check the Veeam knowledge base for the latest fixed build of Veeam Agent for Microsoft Windows. If a patched version is not yet available, contact Veeam support for an interim hotfix.
  • Restrict log file access. As a temporary mitigation, modify the ACL on C:\ProgramData\Veeam\Endpoint\Svc.VeeamEndpointBackup.log to remove Users read access. Note: Veeam may recreate the file with default permissions on service restart, so verify persistence after reboot and reapply as needed. This does not fully remediate the underlying session-binding flaw but raises the exploitation bar.
  • Limit interactive local users on any Veeam-protected host where patching is delayed. Disable unused local accounts, enforce least-privilege group membership, and audit who has interactive logon rights.
  • Deploy EDR detection content. Monitor for processes executing with a parent of Veeam.EndPoint.Service.exe or VeeamAgent.exe that produce unexpected child processes (e.g., cmd.exe, powershell.exe, whoami.exe) — especially when spawned by a session context that does not match the service account's expected behavior.
  • Enable Sysmon Event ID 1 (Process Create) and alert on command-line patterns referencing the named pipe path or the Svc.VeeamEndpointBackup.log file being accessed by non-admin SIDs.

Strategic Actions

  • Audit backup agent deployment across your estate. You cannot defend what you have not inventoried. Identify every endpoint running Veeam Agent v13.x and prioritize patching on multi-user systems first.
  • Review backup agent architecture. Consider whether backup agents on shared interactive endpoints are necessary, or whether centralized, agentless backup approaches reduce this attack surface.
  • Incorporate LPE vulnerabilities into your threat model for ransomware readiness. Attackers increasingly chain initial access + LPE + backup tampering before deploying encryptors. Every local privilege escalation path on a backup-protected host is a potential ransomware accelerant.

The window between PoC publication and mass exploitation is shrinking. With working exploit code already on GitHub and the attack path requiring only read access to a log file, defenders should assume this will be folded into commodity malware and post-exploitation toolkits within days. Patch or mitigate today — not on the next maintenance cycle.