Veeam Backup & Replication RCE (CVE-2024-40711)

What to do

1. Upgrade Veeam Backup & Replication to 12.2.0.334 or the latest supported release
2. Isolate backup servers: block the Veeam services from user subnets, VPN pools and the internet
3. Enforce MFA on VPNs and remote access, the initial access path seen in the ransomware cases
4. Audit local administrator accounts on backup servers and remove any you did not create
5. Verify you hold immutable or offline backup copies the backup server itself cannot delete

How to check if you are affected or compromised

• Look for new local accounts (Sophos reported names such as 'point' and 'point2') added to Administrators on the Veeam server
• Review VPN logs for logins from unknown IPs or accounts without MFA shortly before backup server activity
• Check for deleted backup jobs, restore points or repositories
• Alert on net.exe or PowerShell spawned by Veeam service processes

What happened#

On September 4, 2024, Veeam published security bulletin KB4649, fixing a batch of flaws across its products. The most serious, CVE-2024-40711 in Veeam Backup & Replication (VBR), is described as allowing "unauthenticated remote code execution (RCE)", rated Critical, CVSS 9.8, and credited to Florian Hauser of CODE WHITE GmbH. It is fixed in VBR 12.2 (build 12.2.0.334). NVD also scores it 9.8 with no privileges required.

watchTowr's analysis (September 9, 2024) explains the bug: a .NET deserialization flaw in VBR's .NET Remoting interface, where a gadget (ObjRef) was missing from a blocklist and could be reached through a whitelisted class. A separate authorization bug let anonymous callers in. Their timeline: build 12.1.0.2131 and earlier were exploitable without credentials; 12.1.2.172 quietly fixed the authorization check, leaving an authenticated variant; 12.2.0.334 is Veeam's full fix.

The sources disagree on authentication. The KB4649 text says "unauthenticated" but the vector shown includes PR:L (low privileges), while NVD and the CNA record use PR:N. watchTowr's reading reconciles it: unauthenticated on older builds, authenticated on 12.1.2.172.

Who is affected#

VBR 12.1.2.172 and all earlier version 12 builds; Veeam says unsupported versions are not tested but likely affected. Backup servers are high-value targets: they hold credentials to much of the estate and control the backups victims need to recover from ransomware.

Do you really need to act?#

Yes. CISA added CVE-2024-40711 to the Known Exploited Vulnerabilities catalog on October 17, 2024, and as of October 21, 2026 the entry marks known ransomware campaign use. Sophos X-Ops reported an activity cluster (STAC 5881) that got in through compromised VPN appliances, then exploited the Veeam flaw to create a local administrator account named "point", in incidents tied to Akira and Fog ransomware and later a new strain, Frag, where a second account "point2" appeared.

watchTowr deliberately withheld its full exploit chain to avoid helping ransomware operators, but that did not prevent real-world use. Even on 12.1.2.172, any valid account could be enough, so "we're past the unauthenticated builds" is not a safe position.

What to do now#

1. Upgrade VBR to 12.2.0.334 or later.
2. Isolate backup infrastructure: the VBR server should not be reachable from user subnets, VPN address pools or the internet. Restrict management access to a dedicated admin network.
3. Require MFA on every VPN and remote access gateway; compromised VPN access was the entry point in the reported cases.
4. Audit local accounts and group memberships on the VBR server.
5. Keep immutable or offline copies that the backup server's own credentials cannot delete, and test restores.

How to tell if you were hit#

On the backup server, look for unfamiliar local accounts, particularly ones added to Administrators (Sophos named "point" and "point2"; names may vary). Run net localgroup administrators and review Security event IDs 4720 (account created) and 4732 (added to a group). Correlate with VPN logs for unusual logins, especially accounts without MFA. Check whether backup jobs, restore points or repositories were deleted or altered, and look for net.exe or PowerShell launched by Veeam service processes. Treat any confirmed sign as a pre-ransomware incident: isolate, rotate credentials stored in Veeam, and verify offline backups before acting.

Timeline#

• Sep 4, 2024 — Veeam publishes KB4649 and VBR 12.2.0.334.
• Sep 9, 2024 — watchTowr publishes analysis, withholds full exploit.
• Oct 17, 2024 — CISA adds CVE-2024-40711 to KEV.
• Nov 8, 2024 — Sophos reports the same tactics delivering Frag ransomware.

Vulnerability records

• CVE-2024-40711 · KEV 2024-10-17 · A deserialization of untrusted data vulnerability with a malicious payload can allow an unauthenticated remote code execution (RCE).

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Veeam — KB4649: Veeam Security Bulletin (September 2024) veeam.com
2. NVD — CVE-2024-40711 nvd.nist.gov
3. CISA — Known Exploited Vulnerabilities Catalog cisa.gov
4. watchTowr Labs — Veeam Backup & Response - RCE With Auth, But Mostly Without Auth (CVE-2024-40711) labs.watchtowr.com
5. Sophos — Veeam exploit seen used again with a new ransomware: Frag sophos.com