CVE-2026-47158

Think of your SSO login like a door that should only open for the right person. In this bug, the login “handshake” checks weren’t tied tightly enough to the exact browser session that started it, so a malicious site could potentially push the flow toward the attacker’s goal. In the worst case, that can lead to someone being logged in as a fully authenticated user, which is similar to getting the keys to the safe rather than just watching from the outside.

This matters if you run Vaultwarden and have SSO enabled (because the vulnerable path is the SSO authorization flow). It is primarily a risk when an attacker can get a user to interact with a malicious page while they are using the SSO login flow. Reachability is therefore tied to whether the SSO authorization endpoints are reachable in your deployment and whether your SSO/browser flow can be triggered by the attacker through a victim’s browser interaction.

Treat this as urgent but not panic-level: it’s a CSRF weakness in the authentication process, which can directly lead to account takeover if the SSO flow is reachable and users interact with a malicious trigger. There is no confirmed KEV listing in CISA, and there is no public exploit code on record, so the risk is less certain—but the impact is high enough to upgrade now rather than waiting.

Confirm exposure

• Identify your Vaultwarden version.
• Confirm whether SSO is enabled and in use (i.e., your users are using the SSO login flow handled by Vaultwarden’s SSO authorization endpoints).

Determine whether you’re affected

• You are affected if your Vaultwarden version is prior to 1.36.0 and you use the SSO authorization flow described in the report.

Upgrade remediation

• Upgrade Vaultwarden to 1.36.0 or later.
• After upgrading, restart Vaultwarden to ensure the updated SSO authorization behavior is active.

Compatibility / breaking-change notes

• No specific breaking changes were provided in the available findings; however, SSO providers sometimes have configuration quirks, so do a quick test login after the upgrade.

Temporary workaround (if you can’t upgrade immediately)

• Reduce exposure by limiting which users can access the SSO login flow and by preventing users from clicking unknown links during the login process (since the attack relies on tricking a browser into interacting with the flow).
• If your environment supports it, temporarily disable SSO login until the upgrade can be applied.

What to monitor

• Check Vaultwarden logs around authentication events for abnormal SSO/login attempts (for example, SSO callbacks that do not match typical user behavior).
• Watch for any evidence of unexpected authenticated sessions created via SSO shortly after unusual browsing activity.

Timeline

• No KEV due date was provided because this issue is not listed in CISA KEV in the provided findings.

Summary and severity

• Product: vaultwarden (Bitwarden-compatible Rust server).
• Weakness: CWE-352 (CSRF).
• Security impact described: SSO authorization flow flaws could allow an unauthenticated attacker to induce IdP authentication and redeem tokens for a fully authenticated session.

Mechanism (how it’s triggered)

• The fix description indicates that prior to 1.36.0, the server did not properly bind the OAuth “state” parameter for /connect/authorize to the initiating browser session.
• It also allowed attacker-influenced PKCE parameters and left SSO authorization records intact after failed token exchange, which together undermined the integrity of the SSO handshake.

Exploitation status

• Not listed in CISA KEV and no public exploit code on record were reported in the provided findings.

Patch status

• A fix is stated as available in Vaultwarden 1.36.0.
• No additional patch details (beyond the version) were provided.

Prediction signals

• EPSS is provided as a prediction, but per instructions it is not repeated in public owner-facing text when KEV/news confirm exploitation. In this case, KEV/news confirmation was not provided in the findings, so exploitation certainty remains unconfirmed.