Veeam disclosed CVE-2026-65641, a critical authentication-coercion vulnerability in Veeam ONE, its monitoring and reporting console for Veeam Backup & Replication environments. The flaw carries a CVSS v4.0 score of 9.3 and was reported through Veeam’s HackerOne bug bounty program. Veeam published the fix as KB4905 on August 25, with wider reporting following August 27.

What happened

CVE-2026-65641 allows a remote, unauthenticated attacker to trigger the Veeam ONE service account into initiating an SMB authentication attempt against an attacker-controlled server. This is a classic forced-authentication / coercion bug: the attacker doesn’t need credentials up front, they just need network reachability to a component that will make Veeam ONE’s backend service account reach out over SMB to a host they control. Once that connection happens, the attacker captures the Net-NTLM authentication exchange.

From there the attacker has the usual NTLM-relay-family options: offline cracking of the captured hash to recover the service account’s plaintext password, or relaying the live authentication attempt to another service on the network (a domain controller, another Windows host, an internal web app using Windows auth) to authenticate as the Veeam ONE service account without ever knowing its password. Which path succeeds depends on the account’s privileges and whether SMB signing / relay mitigations are in place on the target service.

Affected: Veeam ONE 13.1.0.7034 and all earlier Veeam ONE 13.x builds. Veeam states legacy 12.x releases are not affected. Fixed in Veeam ONE 13.1.0.7233 (13.1 Patch 0) and Veeam ONE 13.0.2.7159 (13.0.2 Patch 1).

Why it matters

Veeam ONE service accounts are frequently over-provisioned in the field — it’s common to find them holding domain-level rights, local admin on managed hosts, or credentials to the same backup repositories and virtualization management APIs (vCenter, Hyper-V) that Veeam Backup & Replication itself uses. That overlap is the real danger here: a coerced NTLM credential from a monitoring product can become a foothold into the backup fabric that’s supposed to be the last line of defense against a ransomware event, not another entry point into it.

Backup infrastructure has been a recurring target this year precisely because compromising it lets an attacker delete recovery points before triggering encryption, turning a contained ransomware incident into an existential one. A credential-coercion bug in the monitoring layer sitting next to that infrastructure is a direct path to exactly that outcome, and it requires no authentication and no user interaction — only network reachability to whatever component exposes the vulnerable code path.

Mitigation — do this now

  • Patch immediately. Update to Veeam ONE 13.1.0.7233 or 13.0.2.7159, per KB4905.
  • Enforce SMB signing on all Windows hosts, especially domain controllers, so a relayed NTLM authentication attempt is rejected rather than accepted.
  • Enable Extended Protection for Authentication (EPA) on services that support it, to further blunt relay attacks even if signing is inconsistently deployed.
  • Restrict outbound SMB (TCP/445) from the Veeam ONE server to only the internal hosts it legitimately needs to reach — block outbound SMB to the broader internet and to arbitrary internal segments.
  • Audit the Veeam ONE service account’s privileges. It should not hold domain admin, local admin beyond what’s strictly required, or backup-repository/virtualization-management credentials it doesn’t need to do its job. Least-privilege here directly limits blast radius if the hash is cracked or relayed.
  • Rotate the service account’s credentials after patching if the server was internet-reachable or on a flat/untrusted network segment prior to remediation.

Cross-reference this against your Veeam Backup & Replication hardening posture — a compromised Veeam ONE service account with lateral reach into VBR is the scenario worth actually testing, not just documenting.