[GH-ISSUE #1867] Hidden secrets are visible for users with "hide password" option enabled. #1087

New issue

Closed

opened 2026-03-03 02:06:10 +03:00 by kerem · 2 comments

kerem commented

2026-03-03 02:06:10 +03:00

Owner

Originally created by @mhooSec on GitHub (Jul 23, 2021).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1867

Subject of the issue

Hidden secrets are visible for users with "hide password" option enabled.

Deployment environment

Your environment (Generated via diagnostics page)

Vaultwarden version: v1.22.1
Web-vault version: v2.20.4b
Running within Docker: true
Environment settings overridden: false
Uses a reverse proxy: true
IP Header check: true (X-Real-IP)
Internet access: true
Internet access via a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Database version: 3.35.4
Clients used: Web
Reverse proxy and version: Nginx 1.18.0 (Ubuntu)
Other relevant information:

Steps to reproduce

1.- Create an organisation
2.- Invite an user to this organisation with role "User" and access control to a specific container with "hide password" checkbox on.
3.- Using the admin user, create a new password entry within the organisation, inside of the collection that we approved to the invited user. Something basic, like an username, a password, and a hidden custom field. Save.
4.- Log in with the newly invited user account, and inspect that entry in the collection. Secrets, such as the password and the hidden custom field, should be hidden.
5.- With this newly invited user account, remove the custom field in that entry and save.
6.- Using the user account, check that entry again. At the bottom of the modal box, there should be a clickable "1" next to Password History. Click and it will reveal the hidden value of the custom field, which was not viewable prior to its deletion.

Expected behaviour

As the organisation specified that secrets should be hidden from this specific user, that user should not be able to retrieve those secrets in any way. Therefore, when clicking "Password History" at the bottom of the entry, the secret value should not be shown if the user access control does not allow so.

Actual behaviour

The user was able to retrieve secrets from the organisation without authorisation.

Thank you for your attention.

Originally created by @mhooSec on GitHub (Jul 23, 2021). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/1867 ### Subject of the issue Hidden secrets are visible for users with "hide password" option enabled. ### Deployment environment ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.22.1 * Web-vault version: v2.20.4b * Running within Docker: true * Environment settings overridden: false * Uses a reverse proxy: true * IP Header check: true (X-Real-IP) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Database version: 3.35.4 * Clients used: Web * Reverse proxy and version: Nginx 1.18.0 (Ubuntu) * Other relevant information: ### Steps to reproduce  1.- Create an organisation 2.- Invite an user to this organisation with role "User" and access control to a specific container with "hide password" checkbox on. 3.- Using the admin user, create a new password entry within the organisation, inside of the collection that we approved to the invited user. Something basic, like an username, a password, and a hidden custom field. Save. 4.- Log in with the newly invited user account, and inspect that entry in the collection. Secrets, such as the password and the hidden custom field, should be hidden. 5.- With this newly invited user account, remove the custom field in that entry and save. 6.- Using the user account, check that entry again. At the bottom of the modal box, there should be a clickable "1" next to Password History. Click and it will reveal the hidden value of the custom field, which was not viewable prior to its deletion. ### Expected behaviour As the organisation specified that secrets should be hidden from this specific user, that user should not be able to retrieve those secrets in any way. Therefore, when clicking "Password History" at the bottom of the entry, the secret value should not be shown if the user access control does not allow so. ### Actual behaviour The user was able to retrieve secrets from the organisation without authorisation. -- Thank you for your attention.

kerem closed this issue

2026-03-03 02:06:10 +03:00

kerem commented

2026-03-03 02:06:11 +03:00

Author

Owner

@BlackDex commented on GitHub (Jul 23, 2021):

This looks like a client (web-vault) issue. Something we do not maintain. For items like this you should go to bitwarden.

@BlackDex commented on GitHub (Jul 23, 2021): This looks like a client (web-vault) issue. Something we do not maintain. For items like this you should go to bitwarden.

kerem commented

2026-03-03 02:06:11 +03:00

Author

Owner

@jjlin commented on GitHub (Jul 23, 2021):

As @BlackDex said, this is implemented on the client side, and Vaultwarden only implements the server side, so this behavior is completely out of Vaultwarden's control.

That said, it does seem like an odd design decision to automatically append deleted "hidden" custom fields to the password history, considering they may or may not be passwords. Also, the unobfuscated password history for a cipher probably should not be shown to users to whom the "hide passwords" option applies.

If you feel strongly about this behavior, you can bring it up with Bitwarden at https://community.bitwarden.com/c/feature-requests/5/ or https://github.com/bitwarden/web/issues (not sure whether they would consider these bugs/issues or feature requests).

I would note that expecting that a "user should not be able to retrieve those secrets in any way" is unrealistic, though. Particularly with the web client, it's trivial for someone who knows what they're doing to use the browser's dev tools to reveal the "hidden" fields.

@jjlin commented on GitHub (Jul 23, 2021): As @BlackDex said, this is implemented on the client side, and Vaultwarden only implements the server side, so this behavior is completely out of Vaultwarden's control. That said, it does seem like an odd design decision to automatically append deleted "hidden" custom fields to the password history, considering they may or may not be passwords. Also, the unobfuscated password history for a cipher probably should not be shown to users to whom the "hide passwords" option applies. If you feel strongly about this behavior, you can bring it up with Bitwarden at https://community.bitwarden.com/c/feature-requests/5/ or https://github.com/bitwarden/web/issues (not sure whether they would consider these bugs/issues or feature requests). I would note that expecting that a "user should not be able to retrieve those secrets in any way" is unrealistic, though. Particularly with the web client, it's trivial for someone who knows what they're doing to use the browser's dev tools to reveal the "hidden" fields.

kerem referenced this issue

2026-03-03 09:08:45 +03:00

[PR #1087] [MERGED] Add support for restricting org creation to certain users #2877