Introduction
A missing rate limit on one API endpoint in Vaultwarden lets attackers brute force user passwords with no throttling, turning an email two factor authentication feature into a credential verification oracle. Many organizations and individuals self host Vaultwarden as their password manager backend, and for them this flaw (CVE-2026-43914, CVSS 7.3) breaks one of the most basic protections against online password guessing.
Vaultwarden is an unofficial, Bitwarden compatible server written in Rust, originally known as bitwarden_rs. The self hosting community uses it widely, as do organizations that want a lightweight, on premises alternative to the official Bitwarden server stack while keeping full compatibility with all Bitwarden client applications. That reach is what makes this vulnerability matter to a broad part of the password management ecosystem.
Technical Information
Root Cause
The vulnerability is in the send_email_login function, which serves the /api/two-factor/send-email-login API endpoint. Vaultwarden's standard authentication paths, including _sso_login, _password_login, and _api_key_login, are all protected by a check_limit_login function that rate limits failed login attempts. The email 2FA login endpoint was not wrapped with that same protection.
This omission by itself would be a rate limiting gap. The real severity comes from the endpoint's differential response behavior. The server returns different HTTP status codes and messages depending on whether the submitted credentials are valid:
| Credential Status | Response Code | Response Message | Attacker Implication |
|---|---|---|---|
| Correct credentials | 200 or 400 | "Two factor not found" (if 400) | Password confirmed valid |
| Incorrect credentials | 400 | "Username or password is incorrect" | Password confirmed invalid |
| Email 2FA disabled | 400 | "Email 2FA is disabled" | Oracle not exploitable |
This pattern turns the endpoint into a reliable authentication oracle. An attacker can submit unlimited password guesses and read correctness straight off the response, with no lockout, no delay, and no alert through the normal brute force detection path.
Attack Flow
- The attacker finds an internet exposed Vaultwarden instance and confirms that email 2FA is enabled at the server level.
- The attacker picks a target email address (username) registered on the instance.
- For each candidate password, the attacker computes the master password hash using PBKDF2 with 600000 iterations, matching Vaultwarden's expected format.
- The attacker sends a POST request to
/api/two-factor/send-email-loginwith the target email, the computed hash, and a dummy device identifier. - The attacker reads the HTTP response. A response of "Username or password is incorrect" means the guess was wrong. A 200 response or "Two factor not found" confirms the password is correct.
- This repeats at an unlimited rate until the correct password is found.
Scope
One nuance matters: this vulnerability affects all users on a Vaultwarden instance where email 2FA is enabled at the server level. Individual users do not need email 2FA configured on their own accounts to be vulnerable. The feature being available at the server configuration level is enough to expose the oracle endpoint.
The vulnerability is classified under CWE-307 (Improper Restriction of Excessive Authentication Attempts). The attack vector is network based, attack complexity is low, no privileges are required, and no user interaction is needed.
Affected Systems and Versions
All Vaultwarden versions before 1.35.4 are affected when email 2FA is enabled at the server level. The fix is in version 1.35.4.
Specifically:
- Vulnerable: Vaultwarden versions before 1.35.4 with email 2FA enabled
- Not vulnerable: Vaultwarden 1.35.4 and later
- Not exploitable: Instances where email 2FA is disabled at the server level (regardless of version)
Vendor Security History
The Vaultwarden 1.35.4 release bundled fixes for several security advisories, which points to a coordinated security response:
| Advisory | Issue Description |
|---|---|
| GHSA-c5rv-q295-7w4g (CVE-2026-43914) | Brute force protection bypass via email 2FA oracle |
| GHSA-w9f8-m526-h7fh | Unauthorized cipher access via known UUID |
| GHSA-h4hq-rgvh-wh27 | Manager level unauthorized collection modification |
| GHSA-r32r-j5jq-3w4m | Manager level modification of unassigned collections |
CVE-2026-33420, affecting the get_org_collections_details endpoint, also impacts version 1.35.4 and earlier. Organizations should watch for later releases that address that issue too.
