RBAC “Can preview password: Deny” bypassed via browser autofill popup eye icon

Community Feedback
1

Hi Passbolt team and community,

I want to report a security concern I discovered while testing the RBAC features in Passbolt Pro.

Setup

  • Passbolt Pro (self-hosted on RHEL 9)

  • Browser extension enabled

  • RBAC configured with a custom role:

    • Can preview password → Deny
    • Can copy password → Allow (for autofill purposes)

The intention was to allow users to benefit from autofill without ever seeing the actual password in plaintext.

This is a common PAM (Privileged Access Management) use case — users authenticate to systems without knowing the credentials.

The Issue

When a user navigates to a site where Passbolt has stored credentials, the browser (Chrome/Firefox) displays its native “Save password?” popup.

This popup includes an eye icon that reveals the password in plaintext — completely bypassing the RBAC restriction:

Can preview password: Deny

Steps to Reproduce

  1. Configure a custom role with:

    • Can preview password → Deny

  2. Assign this role to a user

  3. Share a credential with this user (Read or Update permission)

  4. User navigates to the site URL

  5. Passbolt extension performs autofill

  6. Browser displays the native “Save password?” popup

  7. User clicks the eye icon in the popup

  8. Password becomes visible in plaintext :white_check_mark:

Result: RBAC restriction is bypassed.

Expected Behavior

The user should not be able to see the password in plaintext in any way, including through browser-native popups.

Actual Behavior

The password is exposed through the browser’s native credential save popup, which the Passbolt extension currently cannot fully control.

Impact

This defeats the purpose of the RBAC setting:

Can preview password: Deny

Organizations using Passbolt for PAM scenarios — where the goal is zero-knowledge access for end users — may be exposed to unintended password disclosure.

Possible Mitigations (Suggestions)

  1. Suppress autofill into browser-visible fields when "Can preview password: Deny" is active

    • Use hidden/masked input injection instead

  2. Document this limitation clearly in the RBAC documentation

    • Ensure administrators understand the security implications

  3. Attempt to suppress the browser-native save popup

    • For example via autocomplete="off" or similar browser-handling techniques where possible

Questions for the Team

  • Is this a known limitation?
  • Is there a recommended workaround to fully prevent password exposure for users with "Can preview password: Deny"?
  • Is this behavior on the roadmap to address?

Thanks for the great product and for considering this feedback.

Looking forward to the community’s thoughts.

2

What you are observing is an inherent limitation of browser-based autofill systems rather than a direct RBAC bypass inside Passbolt itself.

For autofill to work, the password must eventually be decrypted client-side and inserted into the page by the browser extension. At that point, the browser has access to the plaintext credential because it needs to submit it over HTTPS to the target server during authentication.

The RBAC setting:

“Can preview password: Deny”

is therefore intended primarily to prevent users from revealing or viewing passwords directly within the Passbolt UI and extension interface. It is not a guarantee that a determined user can never access the plaintext once autofill is permitted.

Any solution that allows a browser to authenticate on behalf of a user inherently exposes the secret to the client environment at some stage, including:

  • browser autofill systems,
  • developer tools,
  • native password save prompts,
  • page scripting in some threat models,
  • or local machine compromise.

So in practice:

  • Autofill allowed → the password must become available client-side at runtime.
  • Absolute non-disclosure of credentials → requires preventing autofill entirely and using alternative PAM/session-brokering approaches.

Your suggestions around documenting the limitation more explicitly are reasonable and helpful, if you have suggestions let me know.