Bitwarden Server EUVD-2026-42367

The attacker must already hold a low-privileged member account in the same Bitwarden organization as the victim (PR:L) and must supply the victim's email plus an attacker-controlled public key in the admin-request body. The deployment must use the admin-approval / Trusted Device Encryption authentication-request path that exposes the approved request via an unauthenticated read endpoint. The key limiting factor is that the forged request must be approved before the vault key becomes readable (CVSS UI:P / passive interaction) - in the admin-approval flow that approval is performed by an organization administrator, so exploitation depends on a privileged approver acting on the attacker's request. Exploitation is confined to Bitwarden Server versions before 2026.6.0; patched servers reject the mismatched-user request outright.

This is a genuine high priority rather than an inflated high-CVSS finding. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N with subsequent-system SC:H/SI:H) describes network reach, low attack complexity, only low privileges (any org member), passive user interaction, and high confidentiality/integrity impact extending to another user's account - consistent with the described theft of a victim's vault key and full account takeover. Publicly available exploit code exists (a detailed write-up plus a VulnCheck advisory), which sharply raises real-world likelihood. The vulnerability is NOT listed in CISA KEV, so there is no evidence of confirmed active exploitation, and no EPSS score was provided in the input, so exploitation probability cannot be quantified here. The one limiting factor is UI:P - the malicious admin-approval request must be approved before the key becomes readable (see exploitation_conditions). Net: an available patch, public exploit, low privilege bar, and password-vault impact make this urgent to remediate despite the absence of KEV/EPSS signals.

An attacker holding an ordinary low-privileged membership in a Bitwarden organization sends a POST /auth-requests/admin-request specifying a victim colleague's email and an attacker-controlled public key. An organization administrator, believing it is a normal device-approval request, approves it; the attacker then fetches the now-approved request from the unauthenticated endpoint, decrypts the victim's vault key with the attacker's private key, and uses the victim-scoped access token to take over the account. Public exploit code and a step-by-step write-up for this chain are available.