CVE-2026-43914
HighSummary
In Vaultwarden, prior to version 1.35.4, there is a vulnerability that allows bypassing brute-force login protection if email 2fa is enabled. The 2fa function send_email_login acts as an oracle, enabling attackers to test username-password combinations without rate limiting.
Risk Assessment
Organizations may be exposed to brute-force attacks, potentially leading to unauthorized access to user accounts, even for those who do not have email 2fa configured.
Recommendation
It is recommended to update Vaultwarden to version 1.35.4 or later to mitigate this vulnerability and consider additional security measures such as limiting login attempts.
Other vulnerabilities in Vaultwarden
See all- CVE-2026-43913High
Vaultwarden, a Bitwarden-compatible server, prior to version 1.35.5 allowed an unconfirmed organization owner to purge the entire organization vault. The organization invite flow did not verify confirmation status, enabling a user invited as an owner to delete data.
- CVE-2026-43912High
Vaultwarden prior to version 1.35.5 does not verify that user and group entries belong to the same organization, allowing unauthorized access to vault data of another organization.
- CVE-2026-47164High
A vulnerability in Vaultwarden prior to 1.36.0 allows an attacker to hijack a victim's account via SSO. The issue is due to missing verification of the IdP email_verified claim when linking an identity to an existing local account.
- CVE-2026-47160Medium
An SSRF vulnerability in Vaultwarden before version 1.36.0 allowed bypassing IP address validation in decimal, hexadecimal, and octal formats during icon fetching, enabling internal network and port scanning.
- CVE-2026-47159Medium
A vulnerability in Vaultwarden prior to version 1.36.0 allowed SSO discovery and pre-validation flow to leak organization-related SSO metadata, including organizationIdentifier values, for arbitrary email addresses. This enabled obtaining a valid pre-validation JWT with only the discovered identifier, facilitating SSO-enabled organization enumeration and authentication workflow abuse.
- CVE-2026-47158High
A vulnerability in Vaultwarden prior to version 1.36.0 allows an unauthenticated attacker to hijack a user session by manipulating the SSO authorization flow. The lack of binding the OAuth state parameter to the browser session and acceptance of attacker-controlled PKCE parameters enable triggering authentication at the identity provider and redeeming tokens.
- CVE-2026-33420Medium
Vaultwarden version 1.35.4 and earlier is missing the has_full_access() authorization check on the get_org_collections_details endpoint (GET /api/organizations/{org_id}/collections/details), which exists on the sibling get_org_collections endpoint. This allows any Manager-role user with accessAll=False and no collection assignments to retrieve names, UUIDs, user-to-collection mappings, and group-to-collection mappings for all collections in the organization. The issue has been fixed in version 1.35.5.
- CVE-2026-31835Medium
Vaultwarden versions 1.35.4 and earlier have a vulnerability in the WebAuthn authentication flow. The validate_webauthn_login() function updates persistent credential metadata (backup_eligible and backup_state flags) based on unverified authenticatorData before signature validation. An attacker who knows the user's password but cannot produce a valid WebAuthn signature can permanently modify the backup flags for that credential. If signature verification fails, the database update is not rolled back. This can lead to persistent denial of service of WebAuthn two-factor authentication. Fixed in version 1.35.5.
Original NVD description (English source)
Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.4, there is a security vulnerability in Vaultwarden that allows bypassing the login brute-force protection if email 2fa is enabled. If email 2fa is enabled, the unprotected 2fa-function send_email_login (email.rs, api endpoint /api/two-factor/send-email-login) also acts as an oracle determining whether a username-password combination is correct. An attacker can abuse that endpoint to brute-force passwords without rate-limiting. This works even for users who don't have email 2fa configured. This vulnerability is fixed in 1.35.4.