# CVE-2026-27803: vaultwarden PrivEsc — Fixed in 1.35.4 🦀 🦀 crates.io Not in CISA KEV HIGH severity # CVE-2026-27803 — vaultwarden HIGH CVE-2026-27803 is a high-severity (CVSS 8.3) Improper Privilege Management vulnerability in vaultwarden. A fix is available for vaultwarden — see the affected versions and patch details below. Vaultwarden: Collection Management Operations Allowed Without \`manage\` Verification for Manager Role Also known as[GHSA-h4hq-rgvh-wh27](/vulnerability/GHSA-h4hq-rgvh-wh27) Published Mar 4, 2026 Updated Oct 28, 2026 Affected 1 pkg Patched 1 / 1 Exploits None indexed Exploitation data as of Nov 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### No confirmed exploitation observed yet - A successful exploit gives an attacker total control of the affected component, not partial access. - CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27803. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.3%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk 0.00%0.29%0.58%0.87%0.1%0.3%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 1 pkg affected 🦀`vaultwarden` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems. ## Description ### Summary Testing confirmed that even when a Manager has `manage=false` for a given collection, they can still perform the following management operations as long as they have access to the collection: - `PUT /api/organizations//collections/` succeeds (HTTP 200) - `PUT /api/organizations//collections//users` succeeds (HTTP 200) - `DELETE /api/organizations//collections/` succeeds (HTTP 200) ### Description - The Manager guard checks only whether the user **can access the collection**, not whether they have `manage` privileges. This check is directly applied to management endpoints. src/auth.rs:816 ``` if !Collection::can_access_collection(&headers.membership, &col_id, &conn).await { err_handler!("The current user isn't a manager for this collection") } ``` - The `can_access_collection` function does **not** evaluate the `manage` flag. src/db/models/collection.rs:140 ``` pub async fn can_access_collection(member: &Membership, col_id: &CollectionId, conn: &DbConn) -> bool { member.has_status(MembershipStatus::Confirmed) && (member.has_full_access() || CollectionUser::has_access_to_collection_by_user(col_id, &member.user_uuid, conn).await || ... ``` - A separate management-permission check exists and includes `manage` validation, but it is **not used** during authorization for the affected endpoints. src/db/models/collection.rs:516 ``` pub async fn is_manageable_by_user(&self, user_uuid: &UserId, conn: &DbConn) -> bool { let Some(member) = Membership::find_confirmed_by_user_and_org(user_uuid, &self.org_uuid, conn).await else { return false; }; if member.has_full_access() { return true; } ... ``` - The actual update and deletion endpoints only accept `ManagerHeaders` and do not perform additional `manage` checks. src/api/core/organizations.rs:608 ``` async fn put_organization_collection_update(..., headers: ManagerHeaders, ...) ``` src/api/core/organizations.rs:890 ``` async fn put_collection_users(..., headers: ManagerHeaders, ...) ``` src/api/core/organizations.rs:747 ``` async fn delete_organization_collection(..., headers: ManagerHeaders, ...) ``` ### Preconditions - The attacker is a **Manager** within the target organization. - The attacker has access to the target collection (`assigned=true`). - The attacker’s permission for that collection is `manage=false`. - A valid API access token has been obtained. ### Steps to Reproduce 1. Confirm that the attacker’s current permissions for the target collection include `manage=false`. image 2. As a control test, verify that update operations fail for collections the attacker cannot access. image 3. Confirm that update operations succeed for the target collection where `manage=false`. image 4. Use `PUT /collections/{col_id}/users` to set `manage=true`, confirming that the attacker can escalate their own privileges. image 5. Verify that deletion of the collection succeeds despite the Manager lacking management rights. image ### Required Minimum Privileges - Organization Manager role (Owner/Admin privileges are not required) - Works even with `access_all=false` - Only access rights to the target collection are required (`manage` privilege is not required) ### Attack Scenario A restricted Manager (intended for read/use-only access) directly invokes the API to update collection settings, elevate their own privileges to `manage=true`, and even delete the collection. This allows the user to bypass operational access restrictions and effectively gain administrator-equivalent control over the collection. ### Potential Impact - **Confidentiality:** Expansion of access scope through unauthorized privilege escalation and configuration changes. - **Integrity:** Unauthorized modification of collection settings and assignments; potential disabling of access controls. - **Availability:** Deletion of collections may disrupt business operations. ## Affected Packages 1 total 1 fixed Ecosystem Package Vulnerable range Fix 🦀crates.io `vaultwarden` all versions 1.35.4`cargo update -p vaultwarden --precise 1.35.4` ## Affected Products 1 product · 1 configurations Application `vaultwarden`dani-garcia < 1.35.4 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vaultwarden, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update vaultwarden to 1.35.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27803 is resolved across your whole dependency graph. 3. ### Workarounds Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable. ## Frequently Asked Questions \## Summary Testing confirmed that even when a Manager has \`manage=false\` for a given collection, they can still perform the following management operations as long as they have access to the collection: \* \`PUT /api/organizations//collections/\` succeeds (HTTP 200) \* \`PUT /api/organizations//collections//users\` succeeds (HTTP 200) \* \`DELETE /api/organizations//collections/\` succeeds (HTTP 200) ## Description \* The Manager guard checks only whether the user \*\*can access the collection\*\*, not whether they have \`manage\` privileges. This check is O3 Security · Impact-Aware SCA ### Is CVE-2026-27803 in your dependencies? Find it across crates.io, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)