[GH-ISSUE #6871] Permission Editing not possible #19332

New Issue

GiteaMirror · 2026-04-25T21:53:18-05:00

GiteaMirror commented

2026-04-25 21:53:18 -05:00

Originally created by @marvineimer-kw on GitHub (Feb 25, 2026).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6871

Prerequisites

I have searched the existing Closed AND Open Issues AND Discussions
I have searched and read the documentation

Vaultwarden Support String

While editing permissions as a Manager, you get logged out after trying to Edit Permissions on a Collection.
Might be caused by the recent Vulnerability-Fix

Vaultwarden Build Version

1.35.4

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

nginx

Host/Server Operating System

Linux

Operating System Version

No response

Clients

Web Vault

Client Version

No response

Steps To Reproduce

Go to Web Vault with a Manager Account
Create New Collection
Select Collection to Edit
Edit Something
Click on Save
You get logged out

With existing Collections it works to edit the Rights

Expected Result

The Setting will be saved.

Actual Result

You get logged out with Error: No Permission

Logs

vaultwarden  | [2026-02-25 06:36:45.154][auth][ERROR] Unauthorized Error: The current user isn't a manager for this collection
vaultwarden  | [2026-02-25 06:36:45.154][vaultwarden::api::core::organizations::_][WARN] Request guard `ManagerHeaders` failed: "The current user isn't a manager for this collection".
vaultwarden  | [2026-02-25 06:36:45.154][response][INFO] (put_organization_collection_update) PUT /api/organizations/<org_id>/collections/<col_id> => 401 Unauthorized

Screenshots or Videos

No response

Additional Context

No response

Originally created by @marvineimer-kw on GitHub (Feb 25, 2026). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6871 ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String While editing permissions as a Manager, you get logged out after trying to Edit Permissions on a Collection. Might be caused by the recent Vulnerability-Fix ### Vaultwarden Build Version 1.35.4 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy nginx ### Host/Server Operating System Linux ### Operating System Version _No response_ ### Clients Web Vault ### Client Version _No response_ ### Steps To Reproduce 1. Go to Web Vault with a Manager Account 2. Create New Collection 3. Select Collection to Edit 4. Edit Something 5. Click on Save 6. You get logged out With existing Collections it works to edit the Rights ### Expected Result The Setting will be saved. ### Actual Result You get logged out with Error: No Permission ### Logs ```text vaultwarden | [2026-02-25 06:36:45.154][auth][ERROR] Unauthorized Error: The current user isn't a manager for this collection vaultwarden | [2026-02-25 06:36:45.154][vaultwarden::api::core::organizations::_][WARN] Request guard `ManagerHeaders` failed: "The current user isn't a manager for this collection". vaultwarden | [2026-02-25 06:36:45.154][response][INFO] (put_organization_collection_update) PUT /api/organizations/<org_id>/collections/<col_id> => 401 Unauthorized ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_

GiteaMirror added the bug label 2026-04-25 21:53:18 -05:00

GiteaMirror closed this issue

2026-04-25 21:53:19 -05:00

GiteaMirror commented

2026-04-25 21:53:20 -05:00

@BlackDex commented on GitHub (Feb 25, 2026):

Are you sure you are a manager for that specific collection? Or that you are a Manager who is able to manage all collections?
If not, then this is the expected endresult.

@BlackDex commented on GitHub (Feb 25, 2026): Are you sure you are a manager for that specific collection? Or that you are a Manager who is able to manage all collections? If not, then this is the expected endresult.

GiteaMirror commented

2026-04-25 21:53:21 -05:00

@marvineimer-kw commented on GitHub (Feb 25, 2026):

I just checked its only with newly created Collections. After creating the Collection you cant edit it. In this case, you are manager of the Collection.
I also Updated the Description.

@marvineimer-kw commented on GitHub (Feb 25, 2026): I just checked its only with newly created Collections. After creating the Collection you cant edit it. In this case, you are manager of the Collection. I also Updated the Description.

GiteaMirror commented

2026-04-25 21:53:21 -05:00

@BlackDex commented on GitHub (Feb 26, 2026):

I'm not able to reproduce this in any way.
I created a new manager with the Manage all collections

That user is able to create, edit and delete collections created by that user.
If i assign a user to the custom role and not enable Manage all collections and grant that user Manage rights to a new Collection, that user is able to adjust rights or rename that collection, but isn't allowed to delete it, which is the intended behavior.

Maybe try to update the user's rights, that might help?
Or, there are group policies applied which might prevent that manager from having manage access? Since least privileges are used if set somewhere if I'm correct.

@BlackDex commented on GitHub (Feb 26, 2026): I'm not able to reproduce this in any way. I created a new manager with the `Manage all collections` <img width="400" height="199" alt="Image" src="https://github.com/user-attachments/assets/75b2f01d-7941-4f5c-8e8f-c35061765217" /> That user is able to create, edit and delete collections created by that user. If i assign a user to the `custom` role and not enable `Manage all collections` and grant that user `Manage` rights to a new Collection, that user is able to adjust rights or rename that collection, but isn't allowed to delete it, which is the intended behavior. Maybe try to update the user's rights, that might help? Or, there are group policies applied which might prevent that manager from having manage access? Since least privileges are used if set somewhere if I'm correct.

GiteaMirror commented

2026-04-25 21:53:21 -05:00

@rafaelfariasbsb commented on GitHub (Feb 26, 2026):

Root Cause Analysis

I investigated this issue and found the bug in the collection creation endpoint at src/api/core/organizations.rs, line 524.

When a Manager without access_all creates a new collection, the code adds a CollectionUser record for them, but with manage=false:

if headers.membership.atype == MembershipType::Manager && !headers.membership.access_all {
    CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, false, &conn).await?;
    //                                                                                    ^^^^^
    //                                                                              manage = false
}

Later, when the Manager tries to edit that collection via PUT /api/organizations/<org_id>/collections/<col_id>, the ManagerHeaders request guard calls Collection::is_coll_manageable_by_user(), which checks for any of these conditions:

users_collections.manage == true — false (the bug)
users_organizations.access_all == true — false (Manager doesn't have access_all)
users_organizations.atype <= Admin — false (Manager is not Admin/Owner)
Group-level access_all or manage — depends on config

Since none of the conditions are met, the guard fails with "The current user isn't a manager for this collection" and returns 401.

Why it wasn't reproduced by @BlackDex

The test was done with a Manager that had Manage all collections enabled, which sets access_all=true on the membership. In that case, the condition on line 523 (!headers.membership.access_all) prevents the code block from executing at all — and the permission check passes through condition #2 above. The bug only manifests when the Manager does not have access_all.

Fix

The last parameter of CollectionUser::save (manage) should be true instead of false. If a Manager has permission to create a collection, they should logically be able to manage it:

- CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, false, &conn).await?;
+ CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, true, &conn).await?;

@rafaelfariasbsb commented on GitHub (Feb 26, 2026): ## Root Cause Analysis I investigated this issue and found the bug in the collection creation endpoint at `src/api/core/organizations.rs`, line 524. When a **Manager without `access_all`** creates a new collection, the code adds a `CollectionUser` record for them, but with `manage=false`: ```rust if headers.membership.atype == MembershipType::Manager && !headers.membership.access_all { CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, false, &conn).await?; // ^^^^^ // manage = false } ``` Later, when the Manager tries to edit that collection via `PUT /api/organizations/<org_id>/collections/<col_id>`, the `ManagerHeaders` request guard calls `Collection::is_coll_manageable_by_user()`, which checks for any of these conditions: 1. `users_collections.manage == true` — **false** (the bug) 2. `users_organizations.access_all == true` — **false** (Manager doesn't have `access_all`) 3. `users_organizations.atype <= Admin` — **false** (Manager is not Admin/Owner) 4. Group-level `access_all` or `manage` — depends on config Since none of the conditions are met, the guard fails with `"The current user isn't a manager for this collection"` and returns 401. ### Why it wasn't reproduced by @BlackDex The test was done with a Manager that had `Manage all collections` enabled, which sets `access_all=true` on the membership. In that case, the condition on line 523 (`!headers.membership.access_all`) prevents the code block from executing at all — and the permission check passes through condition #2 above. The bug only manifests when the Manager does **not** have `access_all`. ### Fix The last parameter of `CollectionUser::save` (`manage`) should be `true` instead of `false`. If a Manager has permission to **create** a collection, they should logically be able to **manage** it: ```diff - CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, false, &conn).await?; + CollectionUser::save(&headers.membership.user_uuid, &collection.uuid, false, false, true, &conn).await?; ```

GiteaMirror commented

2026-04-25 21:53:22 -05:00

@BlackDex commented on GitHub (Feb 26, 2026):

Nice that AI found something, but a non-access all manager isn't allowed to create collections if I'm not mistaking.

I can try and check again.

@BlackDex commented on GitHub (Feb 26, 2026): Nice that AI found something, but a non-access all manager isn't allowed to create collections if I'm not mistaking. I can try and check again.

GiteaMirror commented

2026-04-25 21:53:22 -05:00

@stefan0xC commented on GitHub (Feb 26, 2026):

a non-access all manager isn't allowed to create collections if I'm not mistaking.

I think you are because currently it just checks
c555f7d198/src/db/models/organization.rs (L517)
so it is not checking whether a Manager has the access_all permission.

And c555f7d198/src/api/core/organizations.rs (L523-L525) also does not prevent a manager from creating a collection without access_all either so this should both be adjusted if it's not intended.

@stefan0xC commented on GitHub (Feb 26, 2026): > a non-access all manager isn't allowed to create collections if I'm not mistaking. I think you are because currently it just checks https://github.com/dani-garcia/vaultwarden/blob/c555f7d1980c8ab3ac8d64b0297e47c621590368/src/db/models/organization.rs#L517 so it is not checking whether a Manager has the `access_all` permission. And https://github.com/dani-garcia/vaultwarden/blob/c555f7d1980c8ab3ac8d64b0297e47c621590368/src/api/core/organizations.rs#L523-L525 also does not prevent a manager from creating a collection without `access_all` either so this should both be adjusted if it's not intended.

GiteaMirror commented

2026-04-25 21:53:23 -05:00

@BlackDex commented on GitHub (Feb 26, 2026):

Ah, yet a nother situation of not fully validating the API Calls.
The web-vault doesn't allow it, but probably the API does, that should be fixed than.

Ill have to check a bit better regarding the rights though, but i think we currently do not allow non access all managers to create collections. I even recently fixed a security issue because of this.

@BlackDex commented on GitHub (Feb 26, 2026): Ah, yet a nother situation of not fully validating the API Calls. The web-vault doesn't allow it, but probably the API does, that should be fixed than. Ill have to check a bit better regarding the rights though, but i think we currently do not allow non access all managers to create collections. I even recently fixed a security issue because of this.

GiteaMirror commented

2026-04-25 21:53:24 -05:00

@stefan0xC commented on GitHub (Feb 26, 2026):

I've just tested it and the web-vault allows Managers without access_all to create new collections.

https://github.com/user-attachments/assets/9a25dd69-771e-45e1-b922-c3bdec4ed7d4

@stefan0xC commented on GitHub (Feb 26, 2026): I've just tested it and the web-vault allows Managers without `access_all` to create new collections. https://github.com/user-attachments/assets/9a25dd69-771e-45e1-b922-c3bdec4ed7d4

GiteaMirror commented

2026-04-25 21:53:24 -05:00

@BlackDex commented on GitHub (Feb 26, 2026):

Ah well, i think i tried that, and was indeed able to do that, but still also able to adjust and delete.

But, as mentioned, ill check again, and see what the correct rights and way should be.

@BlackDex commented on GitHub (Feb 26, 2026): Ah well, i think i tried that, and was indeed able to do that, but still also able to adjust and delete. But, as mentioned, ill check again, and see what the correct rights and way should be.

GiteaMirror commented

2026-04-25 21:53:25 -05:00

@rafaelfariasbsb commented on GitHub (Feb 26, 2026):

Thanks for the additional context. Based on the discussion, it seems there are two possible approaches here:

A) Allow non-access_all Managers to create collections (current web vault behavior):
The fix would be as proposed in the PR — set manage=true when saving the CollectionUser record, so the creating Manager can manage their own collection.

B) Restrict collection creation to Managers with access_all only:
The fix would be to add a validation check in the creation endpoint to reject requests from Managers without access_all, aligning the API with stricter permission rules.

@BlackDex which approach do you consider correct? I can adjust the PR accordingly.

@rafaelfariasbsb commented on GitHub (Feb 26, 2026): Thanks for the additional context. Based on the discussion, it seems there are two possible approaches here: **A) Allow non-`access_all` Managers to create collections (current web vault behavior):** The fix would be as proposed in the PR — set `manage=true` when saving the `CollectionUser` record, so the creating Manager can manage their own collection. **B) Restrict collection creation to Managers with `access_all` only:** The fix would be to add a validation check in the creation endpoint to reject requests from Managers without `access_all`, aligning the API with stricter permission rules. @BlackDex which approach do you consider correct? I can adjust the PR accordingly.

GiteaMirror commented

2026-04-25 21:53:25 -05:00

@uedvt359 commented on GitHub (Mar 3, 2026):

Restricting collection creation to manage_all managers would be very bad for our use case.

We are using Vaultwarden in our Office. Each team has one VW-manager who creates collections. If creating collections would require manage_all, then the VW-manager of Team A could modify the access rights to collections of Team B - including inviting themselves to passwords they shouldn't have access to.

That would be a net-negative, in terms of security.

Looking upstream to Bitwarden, restricting collection creation (and separately, collection deletion) is an opt-in feature, configurable per-organisation: https://bitwarden.com/help/collection-management/#restrict-collection-creation-to-owners-and-admins
This is by default not enabled - by default, all managers can create and delete collections!

@uedvt359 commented on GitHub (Mar 3, 2026): Restricting collection creation to manage_all managers would be very bad for our use case. We are using Vaultwarden in our Office. Each team has one VW-manager who creates collections. If creating collections would require manage_all, then the VW-manager of Team A could modify the access rights to collections of Team B - including inviting themselves to passwords they shouldn't have access to. That would be a net-negative, in terms of security. Looking upstream to Bitwarden, restricting collection creation (and separately, collection deletion) is an opt-in feature, configurable per-organisation: https://bitwarden.com/help/collection-management/#restrict-collection-creation-to-owners-and-admins This is by default not enabled - by default, all managers can create and delete collections!

GiteaMirror commented

2026-04-25 21:53:26 -05:00

@BlackDex commented on GitHub (Mar 16, 2026):

I understand that the use case described here would be broken by a current pending PR, but since this currently is how Vaultwarden works, and the more customized RBAC is not yet available in Vaultwarden, this currently is how Vaultwarden works until the more fine-grained RBAC is available.

There, this is currently how Vaultwarden should work and therefor is a works-as-intended.

@BlackDex commented on GitHub (Mar 16, 2026): I understand that the use case described here would be broken by a current pending PR, but since this currently is how Vaultwarden works, and the more customized RBAC is not yet available in Vaultwarden, this currently is how Vaultwarden works until the more fine-grained RBAC is available. There, this is currently how Vaultwarden should work and therefor is a works-as-intended.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#19332