Vaultwarden CVE-2026-43914

The server-side email 2FA feature must be enabled on the Vaultwarden instance - this is the hard precondition. When it is enabled, /api/two-factor/send-email-login can be abused as a password oracle against ALL users on the instance, including those who have not configured email 2FA for their own account. If email 2FA is disabled the endpoint returns 'Email 2FA is disabled' and cannot be abused, so instances without email 2FA are not affected. No authentication is required to call the endpoint (PR:N). The practical limiting factor is password strength: guessing must defeat client-side PBKDF2-SHA256 hashing (600k iterations by default, retrievable per-user from /identity/accounts/prelogin), so weak or reused master passwords are the realistic exposure, and strong passwords remain resistant even without rate limiting.

The signals conflict sharply and must be weighed together. The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H = 9.8) frames this as a trivially remote, unauthenticated, full-impact flaw, and the vuln.today Decision label is act_now. However, the mechanism is narrower than 9.8 implies: CWE-307 (improper restriction of excessive authentication attempts) means the bug does not directly disclose or alter data - it removes the brute-force rate limit and turns /api/two-factor/send-email-login into a username/password oracle. Actual compromise still requires guessing a master password that is hashed client-side with PBKDF2-SHA256 (600k iterations by default), so success depends on password strength. This is consistent with SSVC Technical Impact: partial rather than total. EPSS is very low (0.04%, 11th percentile) and the CVE is NOT in CISA KEV, indicating no evidence of widespread or active exploitation despite the high CVSS. The counterweight is that SSVC marks Automatable: yes and a working PoC is published, so opportunistic scanning of exposed instances is realistic. Net: treat as a genuine priority for any internet-exposed Vaultwarden instance with email 2FA enabled (per the act_now label and the attractiveness of a password-vault target), but recognize the 9.8 overstates immediacy - low EPSS and partial technical impact suggest this is a credential-cracking enabler gated by password strength, not a direct one-shot account takeover.

An attacker who can reach a Vaultwarden server that has email 2FA enabled repeatedly POSTs candidate master-password hashes for a target email to /api/two-factor/send-email-login; the endpoint is not covered by check_limit_login, so it answers 'Username or password is incorrect' for wrong guesses and returns HTTP 200 / 'Two factor not found' for the correct one, leaking validity with no rate limiting. A public PoC Python script in the GHSA advisory automates this and works against every user on the instance - even users who never configured email 2FA themselves. Exploitation is network-based and unauthenticated (PR:N), but ultimate vault access still hinges on the victim's password being guessable.