GHSA-h4hq-rgvh-wh27 Vaultwarden's Collection Management Operations Allowed Without `manage` Verification for Manager Role
SummaryTesting 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/<org_id>/collections/<col_id>` succeeds (HTTP 200)`PUT /api/organizations/<org_id>/collections/<col_id>/users` succeeds (HTTP 200)`DELETE /api/organizations/<org_id>/collections/<col_id>` succeeds (HTTP 200)DescriptionThe 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:816The `can_access_collection` function does **not** evaluate the `manage` flag.
src/db/models/collection.rs:140A 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:516The actual update and deletion endpoints only accept `ManagerHeaders` and do not perform additional `manage` checks.
src/api/core/organizations.rs:608src/api/core/organizations.rs:890src/api/core/organizations.rs:747PreconditionsThe 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 ReproduceConfirm that the attacker’s current permissions for the target collection include `manage=false`.
<img width="2015" height="636" alt="image" src="https://github.com/user-attachments/assets/58ddc733-e37c-4766-a980-b1ea1918ceb4" />As a control test, verify that update operations fail for collections the attacker cannot access.
<img width="2021" height="852" alt="image" src="https://github.com/user-attachments/assets/d8699442-2dfc-4d73-8940-ec10f4a175f0" />Confirm that update operations succeed for the target collection where `manage=false`.
<img width="2013" height="690" alt="image" src="https://github.com/user-attachments/assets/33d9845d-d18e-456c-a58c-e780911347a9" />Use `PUT /collections/{col_id}/users` to set `manage=true`, confirming that the attacker can escalate their own privileges.
<img width="2018" height="488" alt="image" src="https://github.com/user-attachments/assets/da8c5246-cf2a-46c2-9a25-e99d907f852d" />Verify that deletion of the collection succeeds despite the Manager lacking management rights.
<img width="2018" height="487" alt="image" src="https://github.com/user-attachments/assets/a97c8fb2-4f97-4c2a-a90b-9d95dbde84fd" />Required Minimum PrivilegesOrganization 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 ScenarioA 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.
CVSS v3.1 score: 8.3