Vaultwarden CVE-2026-43911

Exploitation requires the attacker to already hold a valid refresh token issued before the security_stamp rotation - obtained out-of-band via device theft, malware, or session hijacking; the flaw cannot be triggered without this pre-existing token. It affects Vaultwarden <= 1.35.4. The defining condition is that the security-sensitive operations which rotate the stamp (password change, KDF change, key rotation, email change, org admin password reset, and emergency access takeover) do NOT delete Device records or rotate the device refresh_token, so stolen refresh tokens survive them. Emergency access takeover is the most dangerous case because it sends no logout notification. Limiting factors: only 'Deauthorize Sessions' (which deletes devices) or an admin action (post_sstamp, deauth_user, disable_user, all of which call Device::delete_all_by_user) actually invalidates the refresh token, so a victim who takes those specific steps is protected.

Signals are mixed and point to a real but non-urgent fix rather than an emergency. The CVSS 3.1 base score is 8.1 (High) with AV:N/AC:L/PR:L/UI:N and C:H/I:H/A:N, reflecting network reachability and total loss of vault confidentiality and integrity once the flaw is triggered. However, exploitation is gated on the attacker already possessing a valid refresh token, which the SSVC framework captures as Exploitation: poc, Automatable: no, Technical Impact: total - i.e., severe impact but no scalable, self-propagating exploitation path. This aligns with the very low EPSS score of 0.03% (8th percentile), indicating no expectation of widespread opportunistic exploitation. The vulnerability is NOT in CISA KEV, so there is no confirmed active exploitation; the low EPSS combined with the precondition of prior token theft is consistent with a targeted, post-compromise persistence problem rather than mass exploitation. The vuln.today decision label is 'this_week', so this should be remediated promptly but is not flagged as act_now/emergency. Net assessment: a genuine, high-impact session-management weakness worth patching on a near-term schedule, not a high-CVSS-but-trivial issue, yet also not a drop-everything event given the required precondition and absent KEV/high-EPSS signals.

An attacker who has already obtained a user's refresh token (via device theft, malware, or session hijacking) retains it while the victim, suspecting compromise, changes their master password, rotates keys, or changes email - actions that rotate the security_stamp and are expected to end all sessions. Because the refresh flow never checks the security stamp, the attacker submits the old refresh token to /identity/connect/token and receives a fresh, fully valid access token, regaining read/write access to the vault. A detailed step-by-step PoC (curl commands tested on v1.35.4) is published in the GitHub Security Advisory, though it is not independently verified here as a weaponized exploit.