Introduction
A logic flaw in Bitwarden Server's organization API key endpoints allowed any authenticated user with SCIM management privileges to retrieve or rotate the SCIM API key without re-entering their master password. That turned a long-lived provisioning credential into a trivially exfiltrable secret. For organizations that rely on SCIM to automate user provisioning through their Identity Provider, this vulnerability exposed persistent out-of-band control over their entire Bitwarden user directory to anyone holding a valid admin session.
Technical Information
Root Cause
The vulnerability resides in OrganizationsController.cs and affects two endpoints:
POST /organizations/{id}/api-keyPOST /organizations/{id}/rotate-api-key
Both endpoints use the same authentication guard, which checks whether the caller has verified their identity via master password before returning sensitive key material. The problematic condition was:
if (model.Type != OrganizationApiKeyType.Scim && !await _userService.VerifySecretAsync(user, model.Secret))
This is a classic short-circuit evaluation issue. When model.Type equals OrganizationApiKeyType.Scim, the first operand (model.Type != OrganizationApiKeyType.Scim) evaluates to false. Because the condition uses a logical AND (&&), the runtime skips the second operand entirely, so VerifySecretAsync is never called. Execution falls through to the else branch, which returns or rotates the SCIM key without any password verification.
The result was a clear asymmetry in authentication requirements across API key types:
| Key Type | Authentication Required (Pre-Fix) | Caller Role Required | Risk Level |
|---|---|---|---|
| Default | Master password | Owner | Low |
| BillingSync | Master password | Owner | Low |
| Scim | Session only | Admin or Custom with ManageScim | High |
The SCIM key had the lowest authentication barrier and the lowest role requirement, yet it granted persistent out-of-band access to user provisioning.
Attack Flow
-
Session Compromise: The attacker obtains a valid session token belonging to a user with
ManageScimpermissions. This includes users with the Admin role or any Custom role whereManageScimis enabled. -
Key Retrieval: The attacker sends a
POSTrequest to/organizations/{id}/api-key, specifyingOrganizationApiKeyType.Scimas the type and putting an arbitrary string in the master password hash field. The server returns a200 OKresponse containing the live SCIM API key. -
Optional Key Rotation: The attacker can also call
/organizations/{id}/rotate-api-keywith the same parameters. This replaces the existing SCIM key with a new one, which locks out the legitimate Identity Provider integration and leaves the attacker holding the only valid key. -
Persistent Access: With the SCIM API key, the attacker can provision new users, remove existing users, and modify groups entirely outside the standard Bitwarden session model. This access persists independently of the original compromised session.
Classification
This vulnerability is classified under CWE 303 (Incorrect Implementation of Authentication Algorithm). The design flaw fits that category: a boolean guard inadvertently exempted SCIM key operations from the password verification requirement that protected every other API key type.
Affected Systems and Versions
| Deployment Type | Affected Versions | Fixed Version | Release Date |
|---|---|---|---|
| Self-Hosted | All versions prior to 2026.4.1 | 2026.4.1 | April 20, 2026 |
| Bitwarden Cloud | All versions prior to May 5, 2026 deployment | Cloud Deployed | May 5 to May 6, 2026 |
The vulnerability affects any Bitwarden Server deployment where SCIM provisioning is configured and at least one user holds Admin or Custom (with ManageScim) permissions.
Vendor Security History
Bitwarden maintains a generally strong security posture. The vendor runs independent security researcher programs and undergoes regular third-party audits by firms such as Cure53. Bitwarden holds SOC2 Type II, SOC3, ISO 27001, and HIPAA compliance certifications.
The response timeline for CVE-2026-43640 was notably efficient. The issue was reported on March 25, 2026, the fix landed in the main branch by April 8, self-hosted customers received it on April 20, and it reached the cloud environment by May 6. Full remediation took approximately six weeks from the initial report.
References
- NVD Entry for CVE-2026-43640
- VulnCheck Advisory: Bitwarden Server Authentication Bypass via SCIM API Key
- Researcher Writeup by Sanjok Karki
- GitHub Pull Request #7403: SCIM Api Key Fix
- GitHub Commit eb251d9
- Bitwarden Server Release v2026.4.1
- Bitwarden SCIM Documentation
- Bitwarden Member Roles and Access Control
- Bitwarden Compliance Certifications
