CVE-2026-43913

Prior to version 1.37.0, Vaultwarden validates the initial icon host and DNS results but passes favicon URLs parsed from attacker-controlled HTML to get_page_with_referer() without applying should_block_host() to the second-stage host. A remote unauthenticated attacker can provide a public page whose favicon uses an IP-literal URL, allowing the Vaultwarden server to reach loopback or private and internal addresses.

Vaultwarden through 1.37.3 omits organization membership status validation from three cipher access-restriction queries, allowing revoked and not-yet-confirmed members to retain read, write, delete, and attachment access to organization ciphers.

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.

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.

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.

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.

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.

Prior to 1.35.5, Vaultwarden does not enforce that a groups_users.users_organizations_uuid entry belongs to the same organization as groups.groups_uuid, nor that a collections_groups.collections_uuid entry belongs to the same organization as collections_groups.groups_uuid. An Admin in Organization A who is only a low-privileged member in Organization B can bind their Org B membership into an Org A group and gain unauthorized access to Org B vault data.

Vaultwarden is a Bitwarden-compatible server written in Rust. Prior to 1.35.5, refresh tokens are not invalidated when the user's security_stamp is rotated by some security-sensitive operations (password change, KDF change, key rotation, email change, org admin password reset, emergency access takeover). This allows an attacker holding a previously obtained refresh token to maintain session access even after the user has taken action to secure their account. This vulnerability is fixed in 1.35.5.

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.