CVE-2026-27802: 
Rust vulnerability analysis and mitigation

CVE-2026-27802 is a privilege escalation vulnerability in Vaultwarden (an unofficial Bitwarden-compatible server written in Rust) that allows a Manager account with restricted access (access_all=false) to gain unauthorized access to collections by exploiting a missing authorization check in the bulk-access API. Discovered and disclosed on March 4, 2026, it affects Vaultwarden versions up to and including 1.35.3, with version 1.35.4 containing the fix. It carries a CVSS v3.1 base score of 8.3 (High) (Github Advisory, Vaultwarden Advisory).

The root cause is an improper authorization check (CWE-269, CWE-863, CWE-266) in the bulk-access API endpoint (src/api/core/organizations.rs), which accepts ManagerHeadersLoose authentication but does not validate per-collection access rights for the supplied collectionIds. As a result, a Manager can include collection IDs they are not assigned to, and the endpoint processes them without invoking the can_access_collection check present in other endpoints. The bulk operation then deletes all existing group and user assignments for those collections and reassigns them — effectively granting the attacker access. By contrast, the standard single-update API correctly enforces authorization and returns HTTP 401 for the same unauthorized collections; after the bulk-access call, the same single-update API returns HTTP 200, confirming the authorization gap (Github Advisory, Vaultwarden Advisory).

Successful exploitation allows an authenticated Manager to gain unauthorized read and write access to restricted collections within their organization, exposing sensitive secrets and credentials stored in those collections (high confidentiality impact). The attacker can also modify collection permission settings and access controls (high integrity impact). Because the bulk operation deletes existing assignments before reassigning them, legitimate users may lose access to their collections, constituting a denial-of-service or sabotage scenario within the organization (low availability impact) (Vaultwarden Advisory, Github Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability requires a valid Manager-level account within the target organization but does not require Owner or Admin privileges, making it accessible to a broader set of potential internal threat actors. The EPSS score is approximately 0.038% (0.06% per GitHub Advisory Database), placing it in the 19th percentile for exploitation likelihood. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Obtain Manager credentials: Authenticate to the target Vaultwarden instance using a valid Manager account that has access_all=false set, and retrieve a Bearer token via the standard API login endpoint.
2. Enumerate collections: Use the API to list all collections within the organization and identify collections not currently assigned to the attacker's account (where assigned=false).
3. Verify authorization boundary: Attempt to modify an unassigned collection via the standard single-update API to confirm it returns 401 Unauthorized, establishing the baseline access control.
4. Invoke the bulk-access API: Send a crafted API request to the bulk-access endpoint (e.g., PUT /api/organizations/{orgId}/collections), including in the payload: the target collection IDs (collectionIds) that are not assigned to the attacker, and the attacker's own membership_id in the users field with assigned=true.
5. Confirm privilege escalation: Verify the bulk-access API returns 200 OK. Re-run the standard single-update API against the previously unauthorized collection and confirm it now returns 200 OK, indicating the attacker has successfully assigned themselves access.
6. Access restricted data: Use the newly granted permissions to read or modify secrets and credentials stored in the previously restricted collections (Vaultwarden Advisory, Github Advisory).

• Network/API Logs: HTTP PUT or POST requests to the bulk-access collections endpoint (e.g., /api/organizations/{orgId}/collections) from a Manager-level account, particularly where the request body includes collectionIds not previously associated with that account.
• Logs: API access logs showing a sequence of: 401 Unauthorized on a single-collection update endpoint, followed immediately by a 200 OK on the bulk-access endpoint for the same collection, followed by a subsequent 200 OK on the single-collection update endpoint — indicating a privilege escalation sequence.
• Application Behavior: Unexpected changes to collection membership or permission assignments, particularly where existing user or group assignments have been deleted and replaced; legitimate users reporting sudden loss of access to collections.
• Audit Trail: Manager accounts appearing in access logs for collections outside their originally assigned scope, especially if access_all was set to false for that account (Vaultwarden Advisory).

Upgrade Vaultwarden to version 1.35.4 or later, which patches the authorization gap in the bulk-access API endpoint by enforcing per-collection access validation consistent with other endpoints (Vaultwarden Advisory, Github Advisory). As an interim measure prior to patching, monitor API logs for unusual bulk-access API calls from Manager accounts targeting collections outside their assigned scope, and audit existing collection assignments for unauthorized changes. Organizations should also review and restrict Manager account privileges where possible, and consider temporarily revoking Manager roles for accounts that do not require them until the patch is applied (Red Hat Bugzilla).

Security news outlets including GBHackers and SecurityOnline covered the vulnerability, framing it alongside other Vaultwarden flaws as a broader risk to self-hosted password manager deployments (GBHackers, SecurityOnline). The vulnerability was reported by researcher odgrso and remediated by BlackDex, the primary Vaultwarden developer, with the advisory published directly on GitHub (Vaultwarden Advisory). Red Hat tracked the issue via Bugzilla with a high severity rating, reflecting concern for downstream users of the package (Red Hat Bugzilla).