{"id":"CVE-2026-27803","aliases":["GHSA-h4hq-rgvh-wh27"],"url":"https://o3.security/vulnerability/CVE-2026-27803","summary":"Vaultwarden: Collection Management Operations Allowed Without `manage` Verification for Manager Role","details":"## Summary\n\nTesting 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:\n\n* `PUT /api/organizations//collections/` succeeds (HTTP 200)\n* `PUT /api/organizations//collections//users` succeeds (HTTP 200)\n* `DELETE /api/organizations//collections/` succeeds (HTTP 200)\n\n\n\n## Description\n\n* 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.\nsrc/auth.rs:816\n ```rust\n\n if !Collection::can_access_collection(&headers.membership, &col_id, &conn).await {\n err_handler!(\"The current user isn't a manager for this collection\")\n }\n ```\n\n* The `can_access_collection` function does **not** evaluate the `manage` flag.\n src/db/models/collection.rs:140\n\n ```rust\n\n pub async fn can_access_collection(member: &Membership, col_id: &CollectionId, conn: &DbConn) -> bool {\n member.has_status(MembershipStatus::Confirmed)\n && (member.has_full_access()\n || CollectionUser::has_access_to_collection_by_user(col_id, &member.user_uuid, conn).await\n || ...\n ```\n\n* A separate management-permission check exists and includes `manage` validation, but it is **not used** during authorization for the affected endpoints.\n src/db/models/collection.rs:516\n\n ```rust\n\n pub async fn is_manageable_by_user(&self, user_uuid: &UserId, conn: &DbConn) -> bool {\n let Some(member) = Membership::find_confirmed_by_user_and_org(user_uuid, &self.org_uuid, conn).await else {\n return false;\n };\n if member.has_full_access() {\n return true;\n }\n ...\n ```\n\n* The actual update and deletion endpoints only accept `ManagerHeaders` and do not perform additional `manage` checks.\n src/api/core/organizations.rs:608\n\n```rust\n async fn put_organization_collection_update(..., headers: ManagerHeaders, ...)\n```\n\n src/api/core/organizations.rs:890\n\n```rust\n async fn put_collection_users(..., headers: ManagerHeaders, ...)\n```\n \n\nsrc/api/core/organizations.rs:747\n\n```rust\n async fn delete_organization_collection(..., headers: ManagerHeaders, ...)\n ```\n\n\n\n## Preconditions\n\n* The attacker is a **Manager** within the target organization.\n* The attacker has access to the target collection (`assigned=true`).\n* The attacker’s permission for that collection is `manage=false`.\n* A valid API access token has been obtained.\n\n\n\n## Steps to Reproduce\n\n1. Confirm that the attacker’s current permissions for the target collection include `manage=false`.\n\"image\"\n\n2. As a control test, verify that update operations fail for collections the attacker cannot access.\n\"image\"\n\n3. Confirm that update operations succeed for the target collection where `manage=false`.\n\"image\"\n\n4. Use `PUT /collections/{col_id}/users` to set `manage=true`, confirming that the attacker can escalate their own privileges.\n\"image\"\n\n5. Verify that deletion of the collection succeeds despite the Manager lacking management rights.\n\"image\"\n\n\n\n## Required Minimum Privileges\n\n* Organization Manager role (Owner/Admin privileges are not required)\n* Works even with `access_all=false`\n* Only access rights to the target collection are required (`manage` privilege is not required)\n\n\n\n## Attack Scenario\n\nA 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.\n\nThis allows the user to bypass operational access restrictions and effectively gain administrator-equivalent control over the collection.\n\n\n\n## Potential Impact\n\n* **Confidentiality:** Expansion of access scope through unauthorized privilege escalation and configuration changes.\n* **Integrity:** Unauthorized modification of collection settings and assignments; potential disabling of access controls.\n* **Availability:** Deletion of collections may disrupt business operations.","published":"2026-03-04T21:40:33.495Z","modified":"2026-08-12T03:51:34.291405147Z","cvss":{"score":8.3,"severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L"},"epss":{"score":0.00287,"percentile":0.21297,"asOf":"2026-09-17"},"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"crates.io","name":"vaultwarden","fixedVersion":"1.35.4"}],"fix":null,"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/27xxx/CVE-2026-27803.json"},{"type":"ADVISORY","url":"https://github.com/dani-garcia/vaultwarden/security/advisories/GHSA-h4hq-rgvh-wh27"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-27803"},{"type":"PACKAGE","url":"https://github.com/dani-garcia/vaultwarden"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-08-12T03:51:34.291405147Z"}}