CVE-2026-27803: 
Rust vulnerability analysis and mitigation

CVE-2026-27803 is a high-severity improper authorization vulnerability in Vaultwarden (an unofficial Bitwarden-compatible server written in Rust) that allows authenticated Managers with manage=false permissions to bypass access controls and perform unauthorized collection management operations. It affects all versions up to and including 1.35.3, with version 1.35.4 containing the fix. The vulnerability was disclosed on March 4, 2026, by security researcher "odgrso" via GitHub's security advisory process. It carries a CVSS v3.1 base score of 8.3 (High) (GitHub Advisory, Vaultwarden Advisory).

The root cause is improper privilege management (CWE-269, CWE-285, CWE-863) in Vaultwarden's authorization logic. The ManagerHeaders guard in src/auth.rs calls can_access_collection() to verify collection access, but this function only checks whether the user has been assigned to the collection — it does not evaluate the manage flag. A separate function, is_manageable_by_user() in src/db/models/collection.rs, correctly validates the manage permission, but it is never invoked by the affected API endpoints (put_organization_collection_update, put_collection_users, delete_organization_collection in src/api/core/organizations.rs). As a result, any Manager with collection access (even with manage=false) can successfully call PUT /api/organizations/<org_id>/collections/<col_id>, PUT /api/organizations/<org_id>/collections/<col_id>/users, and DELETE /api/organizations/<org_id>/collections/<col_id> (GitHub Advisory).

An authenticated attacker holding the Manager role with access to a target collection (but manage=false) can modify collection settings, reassign collection users (including escalating their own privileges to manage=true), and permanently delete collections. This results in unauthorized data integrity modification, potential expansion of the attacker's access scope to administrator-equivalent control over collections, and availability disruption through collection deletion. Sensitive credentials and secrets stored within affected collections may be exposed or rendered inaccessible (Vaultwarden Advisory, GBHackers).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time. Exploitation requires an authenticated session with at least the Manager role and collection access, limiting the attack surface to insider threats or compromised accounts. The EPSS score is approximately 0.038% (19th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a Vaultwarden instance running version 1.35.3 or earlier. Confirm the attacker holds a Manager role within the target organization and has been assigned access to at least one collection with manage=false.
2. Obtain API token: Authenticate to the Vaultwarden API using valid credentials to retrieve a valid Bearer token (e.g., via POST /api/accounts/login).
3. Verify preconditions: Confirm the target collection's current permissions show manage=false for the attacker's account by querying GET /api/organizations/<org_id>/collections/<col_id>/users.
4. Escalate privileges: Send a crafted PUT /api/organizations/<org_id>/collections/<col_id>/users request with the Authorization header set to the attacker's Bearer token, modifying the attacker's own entry to set manage=true. The server returns HTTP 200 despite the manage=false restriction.
5. Modify collection settings: Use PUT /api/organizations/<org_id>/collections/<col_id> to alter collection configuration (e.g., rename, change access settings), bypassing intended restrictions.
6. Delete collection (optional): Send DELETE /api/organizations/<org_id>/collections/<col_id> to permanently remove the collection, causing data loss and service disruption (GitHub Advisory).

• Network/API Logs: Unexpected HTTP 200 responses to PUT /api/organizations/<org_id>/collections/<col_id> or PUT /api/organizations/<org_id>/collections/<col_id>/users from accounts known to have manage=false permissions.
• Network/API Logs: DELETE /api/organizations/<org_id>/collections/<col_id> requests resulting in HTTP 200 from non-admin Manager accounts.
• Application Logs: Sudden changes in collection user assignments, particularly self-escalation of manage flag from false to true for a Manager-role account.
• Application Logs: Collection deletion events not initiated by Owners or Admins.
• Behavioral: A Manager account performing collection management operations outside of normal business hours or from unusual IP addresses.

Upgrade Vaultwarden to version 1.35.4 or later, which patches the vulnerability by ensuring the manage flag is properly evaluated before allowing PUT and DELETE operations on collections. No configuration-based workaround is available that fully mitigates the issue without patching. As interim measures, administrators should review Manager role assignments, restrict collection access to only necessary users, and monitor API logs for unauthorized collection modification or deletion activity (Vaultwarden Advisory, Red Hat Bugzilla).

Security news outlets including GBHackers, SecurityOnline, and ITSecurityNews covered the vulnerability shortly after disclosure, framing it alongside other Vaultwarden flaws as enabling privilege escalation and data exposure. The Mastodon account @thehackerwire also shared coverage of the issue. Red Hat tracked the vulnerability via Bugzilla (Bug 2444678) and rated it high severity. Community reaction has been moderate, with no significant controversy or widespread alarm given the low exploitation probability and the availability of a patch (GBHackers, SecurityOnline, Red Hat Bugzilla).