In the course of two weeks in May 2025, Cure53 conducted a comprehensive white-box security audit and penetration test of the Passbolt browser addon and API. The scope covered both frontend and backend/API components, with a total of six findings, four classified as vulnerabilities, and two as informational issues.
While no critical vulnerabilities were discovered, a known limitation affecting metadata integrity was flagged. It is highlighted here, to ensure administrators can properly account for it in their threat models, while awaiting for a future fix. You can read our summary below, or access the full report here.
Missing signature validation allows data-tampering (PBL-13-005) (High)
Passbolt's browser addon encrypts metadata using either the user’s public key or a shared key, and signs it to guarantee integrity. However, the browser extension (and other clients) currently does not verify these signatures during decryption. This means that an attacker with database access could modify metadata without the client proactively detecting any tampering. While confidentiality of existing metadata remains intact, integrity is not guaranteed, and users may unknowingly act on forged metadata.
This limitation is a known and deliberate design choice, as this limitation was already present in version 4. Indeed, the primary focus of version 5 was to reinforce confidentiality while laying the foundation for more robust metadata management.
Future versions of the product will address this gap by introducing on-demand signature validation. Instead of verifying every resource's metadata signatures upfront, which would be computationally intensive, Passbolt will validate signatures asynchronously, for example when users interact with individual resources (as in click or select for example). This approach will ensure data integrity while maintaining performance and responsiveness. A new icon in the sidebar UI will expose signature verification details when one or more resources are selected, giving users confidence in the authenticity of what they see before taking further action.
CSV injection in passwords export (PBL-13-002) (Medium)
When exporting credentials to CSV, malicious users can inject formula-based payloads in the name field (e.g., =HYPERLINK(...)). If opened in spreadsheet software like Excel or Google Sheets, these fields can leak plaintext passwords via crafted URLs, potentially exposing sensitive data.
While this is a known attack vector (currently excluded from the scope of the bug bounty program, Passbolt considers it a lower risk given user control over the export process. Cure53 recommended using the escapeFormulae option available in newer Papa Parse versions. Passbolt team will support it in the future as an option via the UI.
HTML injection in email notification via first name (PBL-13-004) (Low)
An authenticated user could inject HTML into their first name field, which then appears unescaped in email notifications. This could allow for phishing attempts using emails.
Sanitization measures have been implemented to prevent unsafe HTML from being rendered in email templates. This was done reusing the already included Purifier::clean function.
Open redirect on MFA step in login (PBL-13-001) (Low)
A lack of proper sanitization in the redirect parameter on MFA endpoints allows attackers to craft phishing links. For example, protocol-relative URLs like ///example.org could redirect users to malicious domains post-authentication.
Sanitization logic has been updated to handle protocol-relative URLs, preventing malicious redirections.
Other issues
DoS in Papa Parse upon CSV file-import (PBL-13-003) (Info)
While not exploitable in the current version (5.4.1), Papa Parse version 5.5.0+ introduced a denial-of-service vulnerability via specially crafted CSV fields. This could crash the parser using infinite loop exploits.
While Passbolt team also considers self-inflicted DOS out of scope, Cure53 reported the issue to Papa Parse upstream, and the fix was shipped in Passbolt 5.2.
Non-cryptographic randomness is used (PBL-13-006) (Info)
Instances of Math.random() were found in non-sensitive parts of the codebase. Although currently benign, this poses a future risk if reused in cryptographic contexts.
Passbolt plans to replace these with cryptographically secure alternatives like crypto.getRandomValues() to future-proof the codebase.
Conclusion
This PBL-13 audit confirms that Passbolt's overall security posture is robust, with no breaches of confidentiality found in the end-to-end encryption flow. The most impactful issue relates to data integrity and will be resolved with upcoming changes in v5.
All other vulnerabilities were either fixed or deemed low priority due to exploitability constraints. The remaining tasks focus on hardening existing mechanisms and reducing the surface area for future misuse.
We would like to thank Cure53 security researchers involved in this assessment for their thorough and professional audit. Their expertise and vigilance continue to play a vital role in helping us strengthen the security of the Passbolt platform.
