Bitwarden vulnerability CVE-2026-60104: Critical Patch Released

The disclosure of a critical Bitwarden vulnerability on July 8, 2026, sent shockwaves through the self-hosted password manager ecosystem. Tracked under the identifier CVE-2026-60104, this high-severity authorization bypass carries a CVSS v3.1 score of 8.7 and a CVSS v4.0 score of 9.3 under certain vectors. The security advisory warns of a devastating flaw in self-hosted Bitwarden Server environments running versions prior to v2026.6.0. Discovered by security researcher Sanjok Karki (@thesanjok) via HackerOne (Report #3676230), the vulnerability resides in the Trusted Device Encryption (TDE) architecture—specifically within the administrative request endpoints. By exploiting this flaw, a low-privileged organization member can bypass fundamental authentication and authorization controls to silently exfiltrate a target user’s symmetric vault decryption key and mint a fully authenticated, victim-scoped session token. This completely compromises the zero-knowledge boundary that underpins the platform, allowing unauthorized users to decrypt and read any stored credentials.

Understanding the Bitwarden Vulnerability and Trusted Device Encryption

To appreciate the severe risk posed by this Bitwarden vulnerability, it is necessary to examine the underlying cryptography of the platform’s passwordless Single Sign-On (SSO) workflow. Traditionally, password managers maintain zero-knowledge by deriving the vault decryption key directly from a master password known only to the user. This master password is never transmitted to the server. However, when an enterprise implements passwordless OIDC or SAML-based SSO, there is no master password to derive this key locally at login.

To facilitate passwordless SSO without centralizing decryption keys on the server, Bitwarden engineered Trusted Device Encryption (TDE). In a TDE-enabled organization, users can authenticate via their Identity Provider (IdP) and decrypt their vault using a key-sharing handshake. This architecture utilizes asymmetric RSA key pairs. A trusted, pre-approved device stores a symmetric “Device Key.” When a user attempts to log in from a new, untrusted device, the server initiates an authentication request flow. This request can be approved via two primary paths:

• Admin Approval: An organization administrator reviews the pending device request in the Admin Console and approves it.
• Device Approval: The user manually approves the prompt from another active, trusted device.

Once the request is approved, the active trusted device or the administrative approval machinery retrieves the victim’s master vault key, encrypts it using the public key supplied by the new device, and uploads this payload to the server. The new device then fetches this encrypted payload, decrypts it using its local private key, and recovers the symmetric vault key to unlock the credentials locally.

The Anatomy of the Exploit: Broken Object-Level Authorization

The core architectural failure behind CVE-2026-60104 lies in the server’s endpoint validation logic, classifying it under CWE-639: Authorization Bypass Through User-Controlled Key (commonly known as Broken Object-Level Authorization, or BOLA). Specifically, the flaw resides in the POST /auth-requests/admin-request endpoint, which handles the creation of device-trust approval requests targeted for administrator review.

When a user initiates an Admin Approval request from a new device, the client triggers a POST request to this endpoint. The request body is mapped to the AuthRequestCreateRequestModel, which contains an arbitrary Email field specifying the identity of the user requesting access, along with an attacker-controlled RSA public key. The server-side controller, located in AuthRequestsController.cs, receives this payload.

Crucially, in affected server versions, the backend service method CreateAuthRequestAsync resolved the target user record from the database using the user-supplied email parameter:

var user = await _userRepository.GetByEmailAsync(model.Email);

However, the server completely failed to verify whether the email address provided in the HTTP request body actually belonged to the authenticated security principal executing the request. It never compared the resolved target user ID (user.Id) against the authenticated caller’s user ID (_currentContext.UserId). Consequently, any authenticated organization member—even a low-privileged “Custom” user with negligible permissions—could craft a request payload containing a victim’s email address and their own attacker-controlled public key, essentially initiating a spoofed trusted device request on behalf of any other user in the organization.

The Exploit Sequence: Vault Key Heist and Session Escalation

The operational execution of this exploit relies on a multi-stage workflow that abuses the trust of administrative oversight. An attacker can systematically hijack another user’s vault through the following series of events:

1. Request Creation: The attacker authenticates to their low-privileged Bitwarden account. They execute a crafted HTTP POST request to the /api/auth-requests/admin-request endpoint, passing the victim’s corporate email address in the body, bound to an RSA public key generated by the attacker’s client.
2. Administrative Deception: Within the organization’s Device Approvals panel in the Bitwarden Portal, a new pending approval appears. Crucially, the UI displays only the victim’s email address (e.g., victim@enterprise.com) making the request indistinguishable from a legitimate trusted device enrollment.
3. The Approval Handshake: A system administrator or organization owner, assuming the request is legitimate, clicks “Approve.” The approval mechanism retrieves the victim’s vault key—often decrypted via the organization’s Account Recovery reset-password-key chain—and encrypts it using the public key provided in the initial request. In this case, it is the attacker’s public key.
4. Key Exfiltration: Because of the unauthenticated design of the response retrieval mechanisms, the approved handshake payload is readable from an anonymous endpoint. The attacker queries this endpoint, obtains the encrypted vault key payload, and decrypts it locally using their private key. The attacker now possesses the victim’s raw, 64-byte symmetric vault decryption key.

On its own, acquiring the symmetric key is only half the battle; the attacker still requires the victim’s encrypted vault ciphertext, which is protected behind separate database and session access controls. However, Sanjok Karki identified a secondary flaw that turned this key leak into a complete, zero-interaction account takeover.

The /auth-requests/admin-request endpoint was intended solely to accept requests of type AuthRequestType.AdminApproval (Type 1). However, the backend did not enforce this restriction. An attacker could submit a request with the type set to AuthenticateAndUnlock (Type 0). When the admin approved this spoofed request, the attacker was able to exchange the approved request directly at the /connect/token IdentityServer endpoint. Because the request was linked to the victim’s identity, the server minted a fully valid, victim-scoped JWT access token. Armed with both the victim-scoped session token and the decrypted vault key, the attacker could download the victim’s vault ciphertext from the server and instantly decrypt all password records locally, bypassing multi-factor authentication and zero-knowledge boundaries.

Systemic Impact on Zero-Knowledge Trust Architectures

CVE-2026-60104 underscores a broader, systemic risk facing modern zero-knowledge architectures when they are adapted for enterprise convenience. Zero-knowledge cryptography is fundamentally fragile; its integrity relies entirely on the premise that raw decryption keys are never handled by, or exposed to, the server.

When organizations introduce convenience features like Trusted Device Encryption or key escrow-based “Account Recovery” to eliminate master passwords, they inevitably introduce administrative trust loops. If the server-side code overseeing these loops fails to perform strict authorization mapping, the physical security of the keys becomes vulnerable to application-level logical flaws. In this case, the human-in-the-loop approval mechanism acted as a cryptographic “laundering” service, unknowingly re-encrypting a victim’s secrets to an adversary’s key. For self-hosted instances protecting highly sensitive critical infrastructure, such flaws represent a catastrophic threat vector.

Remediation and Hardening Guidelines for Administrators

Bitwarden has addressed this critical vulnerability in its v2026.6.0 server release, followed by minor security maintenance patches (such as v2026.6.2). The patch modifies the API controller to strictly enforce that the request type is AdminApproval and asserts that the resolved target user’s ID matches the authenticated caller’s security context (PR #7615, commit dcf4c486).

For self-hosted administrators, immediate action is required to secure their deployments. The following security steps should be executed immediately:

1. Upgrade Self-Hosted Instances

Deployments running on self-hosted Docker environments must pull the latest secure images. Log in to the host server and execute the standard Bitwarden update utility:

./bitwarden.sh updateself
./bitwarden.sh update

Once the update completes, verify that the active running API version is 2026.6.0 or higher.

2. Disable Admin Approval Organizational Policy

If immediate patching is unfeasible due to enterprise change-management constraints, administrators must immediately mitigate the attack vector by disabling the policy. Navigate to the Bitwarden Admin Portal, select your Organization, and go to Settings > Policies. Locate the Device Approvals policy and disable the Admin Approval option. This forces users to rely exclusively on local trusted device approvals, removing the vulnerable API endpoint from the active attack surface.

3. Log Auditing and Threat Hunting

Security Operations Center (SOC) teams should audit historical server access logs to detect potential exploitation attempts. Search web server and reverse proxy logs (such as Nginx, IIS, or Traefik logs) for anomalous POST requests directed at the following endpoint:

POST /api/auth-requests/admin-request

Correlate these requests with the authenticated user ID and the email address provided in the HTTP payload. Any mismatch between the authenticated user session and the target email is a strong indicator of compromise (IoC) and should trigger immediate incident response protocols.