[GH-ISSUE #6269] "Edit items, hidden passwords" permission issue #29878

New Issue

GiteaMirror · 2026-06-17T09:32:57-05:00

GiteaMirror commented

2026-06-17 09:32:57 -05:00

Originally created by @scarab714 on GitHub (Sep 3, 2025).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6269

Prerequisites

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

Vaultwarden Support String

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.34.3
Web-vault version: v2025.7.0
OS/Arch: linux/aarch64
Running within a container: true (Base: Debian)
Database type: SQLite
Database version: 3.50.2
Uses config.json: true
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Browser/Server Time Check: true
Server/NTP Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Websocket Check: true
HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: DOMAIN, SENDS_ALLOWED, SIGNUPS_ALLOWED, EMERGENCY_ACCESS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 10,
  "admin_ratelimit_seconds": 60,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "***************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*************************",
  "domain_origin": "*****://*************************",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "",
  "org_events_enabled": false,
  "org_groups_enabled": true,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "push_enabled": true,
  "push_identity_uri": "https://identity.bitwarden.eu",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://api.bitwarden.eu",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": true,
  "signups_domains_whitelist": "",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*****************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "*****************************",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "*****************",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Vaultwarden Build Version

1.34.3

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

nginx

Host/Server Operating System

Linux

Operating System Version

Ubuntu 24.04

Clients

Desktop. It's not related to client issue.

Client Version

2025.8.2 (46635)

Steps To Reproduce

Steps to Reproduce
1. Log in with a user who has “Edit items, hidden passwords” permission on Collection A.
2. Locate an item in Collection A where the password field is hidden (not viewable).
3. Edit this item and add Collection B to its collection assignments.
• (The user also has full access to Collection B.)
4. Save the changes.
5. Open the item again from Collection B.

Expected Result

Based on the fix Bitwarden has done, a user with “Edit items, hidden passwords” should not be able to reassign items to other collections, nor gain access to hidden passwords by doing so.

Actual Result

The user can see the password of the item moved to Collection B, even though in Collection A it was hidden.

Logs

Screenshots or Videos

Additional Context

I'm facing an issue on vaultwarden that are already been reported and fixed for Bitwarden.

During practical testing, I found that, despite having limited permissions, it was possible to bypass the restriction on hidden passwords. Specifically, by taking an item from a collection where I only had the “Edit items, hidden passwords” permission and adding it to another collection where I had full access, I was able to view the password of that item. This demonstrates that the “Edit items, hidden passwords” permission allowed a form of reassignment of items that should not have been possible. According to the documentation, this permission is supposed to allow editing of items without granting the ability to change their collection assignments or reveal hidden passwords. The expected behavior is that a user with this permission should not be able to move items into collections where they could gain access to the hidden passwords.

This seems to have been fixed on bitwarden within 2025.2.0 update.
https://bitwarden.com/help/releasenotes/#2025-2-0

Update to "Edit items, hidden passwords" permission: To increase security, the "Edit items, hidden passwords" permission will no longer allow users to assign items within the collection to another collection.

I'm using latest version of vaultwarden 1.34.3

Originally created by @scarab714 on GitHub (Sep 3, 2025). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/6269 ### 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 ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.34.3 * Web-vault version: v2025.7.0 * OS/Arch: linux/aarch64 * Running within a container: true (Base: Debian) * Database type: SQLite * Database version: 3.50.2 * Uses config.json: true * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Websocket Check: true * HTTP Response Checks: true ### Config & Details (Generated via diagnostics page) <details><summary>Show Config & Details</summary> **Environment settings which are overridden:** DOMAIN, SENDS_ALLOWED, SIGNUPS_ALLOWED, EMERGENCY_ACCESS_ALLOWED, ADMIN_TOKEN, SMTP_HOST, SMTP_SECURITY, SMTP_PORT, SMTP_FROM, SMTP_FROM_NAME, SMTP_USERNAME, SMTP_PASSWORD **Config:** ```json { "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "***:", "admin_ratelimit_max_burst": 10, "admin_ratelimit_seconds": 60, "admin_session_lifetime": 20, "admin_token": "***", "allowed_connect_src": "", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "***************", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*************************", "domain_origin": "*****://*************************", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": true, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "experimental_client_feature_flags": "", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 120, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "X-Real-IP", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": null, "org_creation_users": "", "org_events_enabled": false, "org_groups_enabled": true, "password_hints_allowed": true, "password_iterations": 600000, "push_enabled": true, "push_identity_uri": "https://identity.bitwarden.eu", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://api.bitwarden.eu", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": true, "signups_domains_whitelist": "", "signups_verify": true, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*****************", "smtp_from_name": "Vaultwarden", "smtp_host": "*****************************", "smtp_password": "***", "smtp_port": 465, "smtp_security": "force_tls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "*****************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": null, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": null, "user_send_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Vaultwarden Build Version 1.34.3 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy nginx ### Host/Server Operating System Linux ### Operating System Version Ubuntu 24.04 ### Clients Desktop. It's not related to client issue. ### Client Version 2025.8.2 (46635) ### Steps To Reproduce Steps to Reproduce 1. Log in with a user who has “Edit items, hidden passwords” permission on Collection A. 2. Locate an item in Collection A where the password field is hidden (not viewable). 3. Edit this item and add Collection B to its collection assignments. • (The user also has full access to Collection B.) 4. Save the changes. 5. Open the item again from Collection B. ### Expected Result Based on the fix Bitwarden has done, a user with “Edit items, hidden passwords” should not be able to reassign items to other collections, nor gain access to hidden passwords by doing so. ### Actual Result The user can see the password of the item moved to Collection B, even though in Collection A it was hidden. ### Logs ```text ``` ### Screenshots or Videos <img width="1016" height="1090" alt="Image" src="https://github.com/user-attachments/assets/ad83185e-a88f-4828-912a-8d6ca7782186" /> <img width="1022" height="1094" alt="Image" src="https://github.com/user-attachments/assets/e1a3b5d0-9b42-4b90-abcf-916ec2d214e8" /> ### Additional Context I'm facing an issue on vaultwarden that are already been reported and fixed for Bitwarden. During practical testing, I found that, despite having limited permissions, it was possible to bypass the restriction on hidden passwords. Specifically, by taking an item from a collection where I only had the “Edit items, hidden passwords” permission and adding it to another collection where I had full access, I was able to view the password of that item. This demonstrates that the “Edit items, hidden passwords” permission allowed a form of reassignment of items that should not have been possible. According to the documentation, this permission is supposed to allow editing of items without granting the ability to change their collection assignments or reveal hidden passwords. The expected behavior is that a user with this permission should not be able to move items into collections where they could gain access to the hidden passwords. This seems to have been fixed on bitwarden within 2025.2.0 update. https://bitwarden.com/help/releasenotes/#2025-2-0 Update to "Edit items, hidden passwords" permission: To increase security, the "Edit items, hidden passwords" permission will no longer allow users to assign items within the collection to another collection. I'm using latest version of vaultwarden 1.34.3

GiteaMirror added the bug label 2026-06-17 09:32:57 -05:00

GiteaMirror closed this issue

2026-06-17 09:32:58 -05:00

GiteaMirror commented

2026-06-17 09:32:58 -05:00

@stefan0xC commented on GitHub (Sep 3, 2025):

With a User that has Edit items, hidden passwords permissions to a collection, I can't change the collection of an item that is only in that collection:

Edit: Tested both with latest and current testing, web-vault v2025.7.0, v2025.8.0 and v2025.8.2 as well as desktop client v2025.8.0 and v2025.8.2. The only weird thing I noticed is that the desktop client does not sync changed permissions immediately, so it's possible to add the collection in the client, after you change the role from Admin to User (which we might want to prevent also for older clients if they don't have that check)...

@stefan0xC commented on GitHub (Sep 3, 2025): With a User that has `Edit items, hidden passwords` permissions to a collection, I can't change the collection of an item that is only in that collection: <img width="961" height="466" alt="Image" src="https://github.com/user-attachments/assets/1accd564-8f33-4269-a09e-48b74b243b16" /> Edit: Tested both with `latest` and current `testing`, web-vault `v2025.7.0`, `v2025.8.0` and `v2025.8.2` as well as desktop client `v2025.8.0` and `v2025.8.2`. The only weird thing I noticed is that the desktop client does not sync changed permissions immediately, so it's possible to add the collection in the client, after you change the role from `Admin` to `User` (which we might want to prevent also for older clients if they don't have that check)...

GiteaMirror commented

2026-06-17 09:32:59 -05:00

@scarab714 commented on GitHub (Sep 3, 2025):

I just made a test again and confirm that I can change the collection by adding a collection where I have the right to see password, and then gain access to the password that was initialy hidden.
And I confirm that both of my test users are User (and not Admin).

About the sync issue, I confirm that during my tests, I need to "Sync vault" each time I do a modification on the web portal.

@scarab714 commented on GitHub (Sep 3, 2025): I just made a test again and confirm that I can change the collection by adding a collection where I have the right to see password, and then gain access to the password that was initialy hidden. And I confirm that both of my test users are User (and not Admin). About the sync issue, I confirm that during my tests, I need to "Sync vault" each time I do a modification on the web portal.

GiteaMirror commented

2026-06-17 09:33:00 -05:00

@scarab714 commented on GitHub (Sep 3, 2025):

I made several tests.
Even on another separated instances that I'm running, and have the same result...

@scarab714 commented on GitHub (Sep 3, 2025): I made several tests. Even on another separated instances that I'm running, and have the same result...

GiteaMirror commented

2026-06-17 09:33:01 -05:00

@scarab714 commented on GitHub (Sep 3, 2025):

I have more information that can help. Sorry for the spam!

I was doing my test with bitwarden client on MacOS (Version 2025.8.2).

On the web client, I have the same result than you. It's grayed out. Now, I assume you also ran your test on the web client.
On the client on iOS on my iphone, it works. I cannot modify the collection. The option is not even shown.
On bitwarden client on Windows (Version 2025.8.2), same as MacOS. I can add a collection and gain access to the password.

It means that the rights configured on the collection are not consistently enforced, as they can vary depending on the client used.

@scarab714 commented on GitHub (Sep 3, 2025): I have more information that can help. Sorry for the spam! I was doing my test with bitwarden client on MacOS (Version 2025.8.2). - On the web client, I have the same result than you. It's grayed out. Now, I assume you also ran your test on the web client. - On the client on iOS on my iphone, it works. I cannot modify the collection. The option is not even shown. - On bitwarden client on Windows (Version 2025.8.2), same as MacOS. I can add a collection and gain access to the password. It means that the rights configured on the collection are not consistently enforced, as they can vary depending on the client used.

GiteaMirror commented

2026-06-17 09:33:01 -05:00

@stefan0xC commented on GitHub (Sep 3, 2025):

Okay, I only used the Linux version of the Desktop client but I can try with the Windows version tomorrow. But yeah, this should probably also be prevented on the server-side.

@stefan0xC commented on GitHub (Sep 3, 2025): Okay, I only used the Linux version of the Desktop client but I can try with the Windows version tomorrow. But yeah, this should probably also be prevented on the server-side.

GiteaMirror commented

2026-06-17 09:33:02 -05:00

@scarab714 commented on GitHub (Sep 4, 2025):

I also noticed something with the desktop version of the client. For example, if you assign the “View Items” permission, users are still able to edit an entry. The changes won’t actually be saved, but the small notification that appears in the top-right corner misleadingly says in green: “Item saved.”
This can easily confuse users into thinking their changes went through. For instance, someone could update a password, assume it was saved, and not realize that it wasn’t.

The only time I actually see an error is when I try to add another collection while still having only the “View Items” permission. In that case, the client correctly shows: “An error has occurred. Cipher is not write accessible.” But for all other edits, the misleading “Item saved” message still appears, even though nothing changes on the server.

I think this is worth mentioning, because it seems like the desktop client is misinterpreting the server’s response. On the other hand, the iPhone and web client behaves correctly: when you only have view rights, all editable fields are grayed out, and the option to add a collection doesn’t even appear.

This looks consistent with what I noticed yesterday about differences in how permissions are enforced between the mobile and desktop clients.
Hopefully, this additional detail will help narrow down where the issue might be and save some time in identifying the cause.

@scarab714 commented on GitHub (Sep 4, 2025): I also noticed something with the desktop version of the client. For example, if you assign the “View Items” permission, users are still able to edit an entry. The changes won’t actually be saved, but the small notification that appears in the top-right corner misleadingly says in green: “Item saved.” This can easily confuse users into thinking their changes went through. For instance, someone could update a password, assume it was saved, and not realize that it wasn’t. The only time I actually see an error is when I try to add another collection while still having only the “View Items” permission. In that case, the client correctly shows: “An error has occurred. Cipher is not write accessible.” But for all other edits, the misleading “Item saved” message still appears, even though nothing changes on the server. I think this is worth mentioning, because it seems like the desktop client is misinterpreting the server’s response. On the other hand, the iPhone and web client behaves correctly: when you only have view rights, all editable fields are grayed out, and the option to add a collection doesn’t even appear. This looks consistent with what I noticed yesterday about differences in how permissions are enforced between the mobile and desktop clients. Hopefully, this additional detail will help narrow down where the issue might be and save some time in identifying the cause.

GiteaMirror commented

2026-06-17 09:33:03 -05:00

@stefan0xC commented on GitHub (Sep 4, 2025):

I can't reproduce that issue with the Windows version of the client either. (And if I try to change an item in a read only collection I don't get a Item saved popup either, only the Cipher is not writable error message.)

Are you sure you are not mixing up the collection permissions? Or maybe are using a user account with either Admin or Owner role?

@stefan0xC commented on GitHub (Sep 4, 2025): I can't reproduce that issue with the Windows version of the client either. (And if I try to change an item in a read only collection I don't get a `Item saved` popup either, only the `Cipher is not writable` error message.) Are you sure you are not mixing up the collection permissions? Or maybe are using a user account with either Admin or Owner role?

GiteaMirror commented

2026-06-17 09:33:03 -05:00

@stefan0xC commented on GitHub (Sep 4, 2025):

In my eyes the issue I can reproduce arrives from the fact that the permission to change a collection is only checked client side so if you had the permission to fully edit a collection (or possible if you use an outdated/malicious client), you can still change the collection of an entry if your permission has been changed to Edit items, hidden passwords - so (if possible) this should probably be restricted to prevent gaining more access than was intended.

@stefan0xC commented on GitHub (Sep 4, 2025): In my eyes the issue I can reproduce arrives from the fact that the permission to change a collection is only checked client side so if you had the permission to fully edit a collection (or possible if you use an outdated/malicious client), you can still change the collection of an entry if your permission has been changed to `Edit items, hidden passwords` - so (if possible) this should probably be restricted to prevent gaining more access than was intended.

GiteaMirror commented

2026-06-17 09:33:04 -05:00

@scarab714 commented on GitHub (Sep 4, 2025):

What???
I can confirm that the two users I’m using for testing are neither Admin nor Owner; they are regular users. Regarding collections, I’m also certain that I’m not mixing up permissions.
I'm tempted to make a video of the tests.

All clients I’ve used are from official Bitwarden sources:
• macOS and iPhone versions from the App Store
• Windows version downloaded directly from Bitwarden

If needed, I can provide the credentials (Admin account + the 2 users) as the instance is not being used yet, so the issue can be reproduced elsewhere. If that would be useful, please let me know. I’m just not sure what the best way would be to share them privately.

@scarab714 commented on GitHub (Sep 4, 2025): What??? I can confirm that the two users I’m using for testing are neither Admin nor Owner; they are regular users. Regarding collections, I’m also certain that I’m not mixing up permissions. I'm tempted to make a video of the tests. All clients I’ve used are from official Bitwarden sources: • macOS and iPhone versions from the App Store • Windows version downloaded directly from Bitwarden If needed, I can provide the credentials (Admin account + the 2 users) as the instance is not being used yet, so the issue can be reproduced elsewhere. If that would be useful, please let me know. I’m just not sure what the best way would be to share them privately.

GiteaMirror commented

2026-06-17 09:33:05 -05:00

@stefan0xC commented on GitHub (Sep 4, 2025):

Are you using groups or are you giving the users direct permission to the collections? I mean, I've tested it with both and it seems to work as expected (the collection of an item only in a collection, where the user only has the edit, hidden passwords permission, cannot be changed by the same user, even if they have access to collections with more access rights). The only thing I can think of right now that could be the source of the error is that the instance you are connecting to is maybe still an outdated version of vaultwarden (which seems unlikely given that the reported support string says it's the latest) but maybe I'm just missing something in the way I'm trying to reproduce the issue.

@stefan0xC commented on GitHub (Sep 4, 2025): Are you using groups or are you giving the users direct permission to the collections? I mean, I've tested it with both and it seems to work as expected (the collection of an item only in a collection, where the user only has the edit, hidden passwords permission, cannot be changed by the same user, even if they have access to collections with more access rights). The only thing I can think of right now that could be the source of the error is that the instance you are connecting to is maybe still an outdated version of vaultwarden (which seems unlikely given that the reported support string says it's the latest) but maybe I'm just missing something in the way I'm trying to reproduce the issue.

GiteaMirror commented

2026-06-17 09:33:06 -05:00

@scarab714 commented on GitHub (Sep 4, 2025):

In this new instance (set up for an association), I enabled groups since we’ll need them. At first, I thought the issue might be related to groups being in BETA, so I repeated the same test on my private instance (used with my family), where groups are not enabled.

The issue occurs in both cases, whether groups are enabled or not, and on both instances.

Both servers are running the latest available Docker image behind "latest" tag (vaultwarden/server:latest) which is v1.34.3

@scarab714 commented on GitHub (Sep 4, 2025): In this new instance (set up for an association), I enabled groups since we’ll need them. At first, I thought the issue might be related to groups being in BETA, so I repeated the same test on my private instance (used with my family), where groups are not enabled. The issue occurs in both cases, whether groups are enabled or not, and on both instances. Both servers are running the latest available Docker image behind "latest" tag (vaultwarden/server:latest) which is v1.34.3

GiteaMirror commented

2026-06-17 09:33:06 -05:00

@stefan0xC commented on GitHub (Sep 4, 2025):

Can you log out of your Bitwarden client and try again?

@stefan0xC commented on GitHub (Sep 4, 2025): Can you log out of your Bitwarden client and try again?

GiteaMirror commented

2026-06-17 09:33:06 -05:00

@scarab714 commented on GitHub (Sep 4, 2025):

I think I’ve identified the cause of the issue!!

I reinstalled the Windows client on a fresh Windows setup and experienced the same problem. That led me to review my server configuration to see what might differ from your tests.

The only setting I had enabled was “Enforce organization data ownership”, which removes the individual vault option.
With this option enabled, both issues occur:

“Edit items, hidden passwords” behaves incorrectly.
“View items” still allows misleading edits and messages.

With this option disabled, everything behaves as expected.

Since I had this option enabled on both of my instances, that’s why I was consistently experiencing the problem. Re-enabling it immediately reproduces the issue.

This suggests that the bug is directly related to the “Enforce organization data ownership” setting in Vaultwarden.

It might be helpful if you could try enabling it in your setup to confirm the behavior.

@scarab714 commented on GitHub (Sep 4, 2025): I think I’ve identified the cause of the issue!! I reinstalled the Windows client on a fresh Windows setup and experienced the same problem. That led me to review my server configuration to see what might differ from your tests. The only setting I had enabled was “Enforce organization data ownership”, which removes the individual vault option. With this option enabled, both issues occur: - “Edit items, hidden passwords” behaves incorrectly. - “View items” still allows misleading edits and messages. With this option disabled, everything behaves as expected. Since I had this option enabled on both of my instances, that’s why I was consistently experiencing the problem. Re-enabling it immediately reproduces the issue. This suggests that the bug is directly related to the “Enforce organization data ownership” setting in Vaultwarden. It might be helpful if you could try enabling it in your setup to confirm the behavior.

GiteaMirror commented

2026-06-17 09:33:07 -05:00

@stefan0xC commented on GitHub (Sep 4, 2025):

Good that we might have found a possible culprit. Looking at the server side code I'm not sure if this might be a client side issue then, because we only seem to care about that policy when we have to enforce it. But I'll check later if I can at least reproduce that issue with that enabled.

@stefan0xC commented on GitHub (Sep 4, 2025): Good that we might have found a possible culprit. Looking at the server side code I'm not sure if this might be a client side issue then, because we only seem to care about that policy [when we have to enforce it](https://github.com/dani-garcia/vaultwarden/blob/a2ad1dc7c3d28834749d4b14206838d795236c27/src/api/core/ciphers.rs#L349). But I'll check later if I can at least reproduce that issue with that enabled.

GiteaMirror commented

2026-06-17 09:33:08 -05:00

@stefan0xC commented on GitHub (Sep 5, 2025):

Yep, that seems to be it. I think the issue might also appear in upstream but I have no way to confirm that as I only have the Premium plan and no access to Enterprise policies.

@stefan0xC commented on GitHub (Sep 5, 2025): Yep, that seems to be it. I think the issue might also appear in upstream but I have no way to confirm that as I only have the Premium plan and no access to Enterprise policies.

GiteaMirror commented

2026-06-17 09:33:08 -05:00

@scarab714 commented on GitHub (Sep 8, 2025):

To check whether this bug also exists in Bitwarden, I first installed the self-hosted, but that requires a license to create an organization. I then created a Bitwarden account on their hosted service to use the "Free Organization" plan. However, the "Enterprise Policies" feature is only available with the Enterprise plan. On all other plans, organization options are more limited and don’t include the ability to configure the "Enforce organization data ownership" setting.
But I finally managed to get a 7-day Enterprise trial
https://bitwarden.com/go/start-enterprise-trial/

I recreated the same environment as my Vaultwarden setup, with 2 users and 2 collections for each of them.
I confirm that the issue does not occur on Bitwarden, even when the "Enforce organization data ownership" setting is enabled.

With "Edit items, hidden passwords" permissions, I cannot add my collection to an item from another collection. Instead, I get the red error message: "An error has occurred. Resource not found."
With "View items" permissions, I can attempt to make changes, but they don’t apply. I get the same "An error has occurred. Resource not found."

I also noticed some UI differences between Bitwarden and Vaultwarden:

On desktop and web, with "View items" permissions, fields in Bitwarden are not grayed out, whereas in Vaultwarden’s web client they are grayed out.

Another odd behavior appeared when I went back to retest in Vaultwarden. After re-enabling "Enforce organization data ownership", I observed:

With "Edit items, hidden passwords", I can still add my organization, but the password remains hidden. Even if I remove the initial organization and keep only mine, the password stays hidden.
With "View items", the misleading edits and error messages still occur, as before.

It seems that toggling "Enforce organization data ownership" off and back on partially changes the behavior in Vaultwarden. However, it’s still inconsistent and differs significantly from Bitwarden.

@stefan0xC
Could you try if you observe the same thing on your side?

If needed, I can also provide my Bitwarden official credential that I have created for testing for the next 6 days before the trial ends.

@scarab714 commented on GitHub (Sep 8, 2025): To check whether this bug also exists in Bitwarden, I first installed the self-hosted, but that requires a license to create an organization. I then created a Bitwarden account on their hosted service to use the "Free Organization" plan. However, the "Enterprise Policies" feature is only available with the Enterprise plan. On all other plans, organization options are more limited and don’t include the ability to configure the "Enforce organization data ownership" setting. But I finally managed to get a 7-day Enterprise trial https://bitwarden.com/go/start-enterprise-trial/ I recreated the same environment as my Vaultwarden setup, with 2 users and 2 collections for each of them. **I confirm that the issue does not occur on Bitwarden, even when the "Enforce organization data ownership" setting is enabled.** - With "Edit items, hidden passwords" permissions, I cannot add my collection to an item from another collection. Instead, I get the red error message: "An error has occurred. Resource not found." - With "View items" permissions, I can attempt to make changes, but they don’t apply. I get the same "An error has occurred. Resource not found." **I also noticed some UI differences between Bitwarden and Vaultwarden:** - On desktop and web, with "View items" permissions, fields in Bitwarden are not grayed out, whereas in Vaultwarden’s web client they are grayed out. **Another odd behavior appeared when I went back to retest in Vaultwarden.** After re-enabling "Enforce organization data ownership", I observed: - With "Edit items, hidden passwords", I can still add my organization, but the password remains hidden. Even if I remove the initial organization and keep only mine, the password stays hidden. - With "View items", the misleading edits and error messages still occur, as before. It seems that toggling "Enforce organization data ownership" off and back on partially changes the behavior in Vaultwarden. However, it’s still inconsistent and differs significantly from Bitwarden. @stefan0xC **Could you try if you observe the same thing on your side?** **If needed, I can also provide my Bitwarden official credential that I have created for testing for the next 6 days before the trial ends.**

GiteaMirror commented

2026-06-17 09:33:09 -05:00

@stefan0xC commented on GitHub (Sep 8, 2025):

Do you think it’s a bug in Bitwarden that needs to be addressed on their side?

I believe that at least part of the issue is with the client. The other part is with the backend (which needs to be adressed by us as already said before https://github.com/dani-garcia/vaultwarden/issues/6269#issuecomment-3248913914 and https://github.com/dani-garcia/vaultwarden/issues/6269#issuecomment-3253067203).

I confirm that the issue does not occur on Bitwarden

You mean that saving the added collection is not saved? But my question is if you can confirm that the issue with the UI (that you can select additional collections in the first place, i.e. the dialog is not greyed out) is also not present?

btw: From a security perspective you should always assume that once you have given a user access to a collection that because they can now decrypt the item they also have the (theoretical) ability to view the items completely even if it has been obscured by the client. So personally I am not sure how much priority we should give this issue but I'll try to look if we can prevent changing the collections on the server side as well to make it at least harder to do something you ideally should not be able to do...

@stefan0xC commented on GitHub (Sep 8, 2025): > Do you think it’s a bug in Bitwarden that needs to be addressed on their side? I believe that at least part of the issue is with the client. The other part is with the backend (which needs to be adressed by us as already said before https://github.com/dani-garcia/vaultwarden/issues/6269#issuecomment-3248913914 and https://github.com/dani-garcia/vaultwarden/issues/6269#issuecomment-3253067203). > I confirm that the issue does not occur on Bitwarden You mean that saving the added collection is not saved? But my question is if you can confirm that the issue with the UI (that you can select additional collections in the first place, i.e. the dialog is not greyed out) is also not present? btw: From a security perspective you should always assume that once you have given a user access to a collection that because they can now decrypt the item they also have the (theoretical) ability to view the items completely even if it has been obscured by the client. So personally I am not sure how much priority we should give this issue but I'll try to look if we can prevent changing the collections on the server side as well to make it at least harder to do something you ideally should not be able to do...

GiteaMirror commented

2026-06-17 09:33:09 -05:00

@scarab714 commented on GitHub (Sep 8, 2025):

You mean that saving the added collection is not saved?

I can confirm that on the Bitwarden server, with "Edit items, hidden passwords" permissions, I’m able to add my collection, but when I click "Save", I get the error message: "An error has occurred. Resource not found."
The good news is that, on the official Bitwarden server, it’s not possible to gain access to the password in this scenario.

But my question is if you can confirm that the issue with the UI (that you can select additional collections in the first place, i.e. the dialog is not greyed out) is also not present?

With official Bitwarden server, nothing is grayed out with web client and desktop client (windows and mac). Except on iphone client where collection button is hidden.

btw: From a security perspective you should always assume that once you have given a user access to a collection that because they can now decrypt the item they also have the (theoretical) ability to view the items completely even if it has been obscured by the client.

I agree, but since we need users to be able to create entries and assign them to collections that they shouldn’t necessarily have access to, this feature is exactly what we need.
For example, in our non-profit organization, the IT admin creates a new email address for the finance team. He saves it in his "IT emails" collection (since he manages the mailbox), but he also needs to be able to give access to the finance team’s by assigning the entry to their collection without having access to their passwords.

If this behavior could be fixed, it would be fantastic. Otherwise, our only workaround is to disable the "Enforce organization data ownership" setting. But that causes new entries to be added to users personal vaults by default, which isn’t practical.

@scarab714 commented on GitHub (Sep 8, 2025): > You mean that saving the added collection is not saved? I can confirm that on the Bitwarden server, with "Edit items, hidden passwords" permissions, I’m able to add my collection, but when I click "Save", I get the error message: "An error has occurred. Resource not found." The good news is that, on the official Bitwarden server, it’s not possible to gain access to the password in this scenario. > But my question is if you can confirm that the issue with the UI (that you can select additional collections in the first place, i.e. the dialog is not greyed out) is also not present? With official Bitwarden server, nothing is grayed out with web client and desktop client (windows and mac). Except on iphone client where collection button is hidden. > btw: From a security perspective you should always assume that once you have given a user access to a collection that because they can now decrypt the item they also have the (theoretical) ability to view the items completely even if it has been obscured by the client. I agree, but since we need users to be able to create entries and assign them to collections that they shouldn’t necessarily have access to, this feature is exactly what we need. For example, in our non-profit organization, the IT admin creates a new email address for the finance team. He saves it in his "IT emails" collection (since he manages the mailbox), but he also needs to be able to give access to the finance team’s by assigning the entry to their collection without having access to their passwords. If this behavior could be fixed, it would be fantastic. Otherwise, our only workaround is to disable the "Enforce organization data ownership" setting. But that causes new entries to be added to users personal vaults by default, which isn’t practical.

GiteaMirror commented

2026-06-17 09:33:10 -05:00

@stefan0xC commented on GitHub (Sep 8, 2025):

I found the issue. We only check if the cipher is read_only and don't check the hide_password parameter when editing collections.

@stefan0xC commented on GitHub (Sep 8, 2025): I found the issue. We only check if the cipher is `read_only` and don't check the `hide_password` parameter when editing collections.

GiteaMirror commented

2026-06-17 09:33:11 -05:00

@scarab714 commented on GitHub (Sep 8, 2025):

Another odd behavior appeared when I went back to retest in Vaultwarden. After re-enabling "Enforce organization data ownership", I observed:

With "Edit items, hidden passwords", I can still add my organization, but the password remains hidden. Even if I remove the initial organization and keep only mine, the password stays hidden.

With "View items", the misleading edits and error messages still occur, as before.

It seems that toggling "Enforce organization data ownership" off and back on partially changes the behavior in Vaultwarden. However, it’s still inconsistent and differs significantly from Bitwarden.

Please disregard this previous statement!!
The what I called “odd behavior” occurred because I forgot to restore the permissions on the other collection.
I can confirm that I now see the exact same behavior as at the beginning when “Enforce organization data ownership” is enabled.

This doesn’t change the conclusion, but I wanted to clarify it to avoid any misunderstanding or the risk of shifting focus to something irrelevant.

@scarab714 commented on GitHub (Sep 8, 2025): > **Another odd behavior appeared when I went back to retest in Vaultwarden.** After re-enabling "Enforce organization data ownership", I observed: > > * With "Edit items, hidden passwords", I can still add my organization, but the password remains hidden. Even if I remove the initial organization and keep only mine, the password stays hidden. > * With "View items", the misleading edits and error messages still occur, as before. > > It seems that toggling "Enforce organization data ownership" off and back on partially changes the behavior in Vaultwarden. However, it’s still inconsistent and differs significantly from Bitwarden. **Please disregard this previous statement!!** The what I called “odd behavior” occurred because I forgot to restore the permissions on the other collection. I can confirm that I now see the exact same behavior as at the beginning when “Enforce organization data ownership” is enabled. This doesn’t change the conclusion, but I wanted to clarify it to avoid any misunderstanding or the risk of shifting focus to something irrelevant.

GiteaMirror commented

2026-06-17 09:33:12 -05:00

@scarab714 commented on GitHub (Sep 8, 2025):

I found the issue. We only check if the cipher is read_only and don't check the hide_password parameter when editing collections.

Waoww!! So nice! It was quick.
Looking forward for the next docker update then :)
Thank you very much!

@scarab714 commented on GitHub (Sep 8, 2025): > I found the issue. We only check if the cipher is `read_only` and don't check the `hide_password` parameter when editing collections. Waoww!! So nice! It was quick. Looking forward for the next docker update then :) Thank you very much!

GiteaMirror commented

2026-06-17 09:33:12 -05:00

@stefan0xC commented on GitHub (Sep 8, 2025):

Could you make a bug report in https://github.com/bitwarden/clients/ so that the UI issue gets fixed?

@stefan0xC commented on GitHub (Sep 8, 2025): Could you make a bug report in https://github.com/bitwarden/clients/ so that the UI issue gets fixed?

GiteaMirror commented

2026-06-17 09:33:13 -05:00

@scarab714 commented on GitHub (Sep 8, 2025):

Done!
https://github.com/bitwarden/clients/issues/16343

@scarab714 commented on GitHub (Sep 8, 2025): Done! https://github.com/bitwarden/clients/issues/16343

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#29878