No fixed build or workaround is published yet. Limit exposure and watch for a patch.
Steps
Written by AI from the record
Check whether your Vaultwarden is using SSO (for example, any configured “connect/authorize” style SSO integration) and confirm your current Vaultwarden version.
If you are running a Vaultwarden version prior to 1.36.0, plan an urgent upgrade.
Upgrade Vaultwarden to 1.36.0 or later and restart the service.
After upgrading, verify SSO logins still work normally and review authentication logs for unusual SSO/login patterns around the same time window as any suspicious activity.
Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.36.0, Vaultwarden's SSO authorization flow did not bind the OAuth state parameter accepted by /connect/authorize to the initiating browser session, allowed attacker-controlled PKCE parameters, and left SsoAuth records intact after failed token exchange, allowing an unauthenticated attacker to induce IdP authentication and redeem tokens for a fully authenticated session. This issue is fixed in version 1.36.0.
In plain language
Written by AI from the record
CVE-2026-47158 is a CSRF weakness in Vaultwarden’s SSO login flow that could let an attacker trick a user into completing an SSO login as the attacker, so businesses using SSO with Vaultwarden should upgrade to 1.36.0 or later.
In Vaultwarden, a CSRF issue in the SSO authorization flow (CWE-352) allowed the server to accept OAuth authorization inputs without properly binding the OAuth “state” to the initiating browser session and mishandled SSO authorization records during failed token exchange; this could let an unauthenticated attacker induce IdP authentication and redeem tokens for a fully authenticated session.
If you're affected
Account takeover risk
Access to stored secrets
Service disruption
Privacy and data exposure
What is it
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.
Who is affected
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.
How urgent is it
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.
What to do — in detail
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.
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.
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
