CVE-2026-64635

This vulnerability allows an attacker to control where a password reset token gets delivered by manipulating the returnUrl parameter in Veeam Service Provider Console's password reset flow. The mechanism is straightforward: after requesting a password reset, the user receives a token via email. The returnUrl parameter specifies where the application redirects the user after they submit the new password. If that parameter isn't validated against an allowlist, an attacker who can intercept or influence the token delivery can redirect the authenticated session to an arbitrary domain—effectively handing over the authentication event itself. Password reset tokens are bearer instruments: possession equals authenticated access. When you let an external actor specify the destination URL, you're giving them control over where that authenticated session lands. This isn't a new attack class—open redirects in authentication flows have been documented since the early 2000s—but the pattern persists because redirect handling is treated as mundane URL construction rather than a trust boundary. The fix is domain allowlisting: password reset redirects should only be permitted to pre-approved domains, ideally restricted to the same origin. If your Veeam deployment exposes the password reset endpoint externally, verify that returnUrl validation is enforced and that it rejects any destination outside the allowlist. The CVSS of 5.3 reflects the direct technical exploit (requiring user interaction), but the risk amplification matters: Service Provider Console manages infrastructure providers who themselves manage customer environments, so a compromised session here can cascade through trust relationships that the scoring model doesn't capture. Check whether your deployment has any custom redirect logic in authentication flows, and treat any parameter-controlled redirect in a security-sensitive context as a finding until proven otherwise.

Reviewed through automated stages and approved by a human before publication.