CVE-2026-43914 is an authentication brute-force protection bypass in Vaultwarden affecting versions prior to 1.35.4 when email-based two-factor authentication is enabled at the server level. The flaw is in the email 2FA login flow exposed through the send_email_login function and its corresponding API endpoint. Unlike other authentication paths that are protected by the normal login rate-limiting mechanism, this endpoint does not enforce the same restriction on repeated authentication attempts. In addition, it returns distinguishable responses based on whether the supplied username and password combination is valid, creating a credential-verification oracle. An attacker can repeatedly submit candidate passwords for a target account and use the endpoint's differential responses to determine when valid credentials have been found, even if the targeted user has not configured email 2FA on their own account.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone Python proof-of-concept for CVE-2026-43914 affecting Vaultwarden versions earlier than 1.35.4. The repo contains one executable script, vw_bf_poc.py, plus a README and .gitignore. The script is the sole exploit implementation and uses only Python standard library modules: argparse, hashlib, http.client, json, sys, and time. The exploit targets Vaultwarden's unauthenticated POST /api/two-factor/send-email-login endpoint when Email 2FA is enabled. Its core capability is to turn that endpoint into a master-password oracle: it computes a Vaultwarden-compatible masterPasswordHash for each candidate password using PBKDF2-HMAC-SHA256, submits the hash along with the victim email and a device identifier, and interprets the HTTP response. A 200 response means the password guess is correct and an OTP email was sent; a 400 response means the password is incorrect. Because the endpoint is not rate-limited like the normal login flow, the script can brute-force candidate passwords without triggering the intended brute-force protections. Code structure is simple: master_password_hash() derives the expected password hash; try_password() performs the HTTP POST request to /api/two-factor/send-email-login; main() parses CLI arguments, loads candidate passwords from either a comma-separated list or a wordlist file, iterates through guesses, and exits on the first successful hit. The exploit does not deliver code execution or a shell; instead, it provides credential discovery against vulnerable Vaultwarden instances. The README documents the vulnerability, explains the root cause, gives usage examples, and includes a Docker-based lab setup using Vaultwarden 1.35.3 and MailHog for reproduction.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
2 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.