Passbolt Pre-CSPN Security Audit Results

In 2025 Passbolt commissioned Quarkslab to perform a security audit and pre-CSPN evaluation, with the objective of evaluating the product's readiness against ANSSI CSPN expectations and identifying potential security weaknesses.

The assessment lasted several weeks and covered the Passbolt backend, browser extension, cryptographic design, documentation, and deployment guidance.

The audit identified six findings: one medium-severity issue, two low-severity issues, and three informational findings. No critical vulnerabilities were discovered, and Quarkslab concluded that Passbolt demonstrates a mature security posture with robust authentication, access control, and cryptographic protections. The assessment found no vulnerabilities affecting the confidentiality or integrity of stored credentials and confirmed that secure development practices are consistently applied throughout the product.

The most significant finding concerns a CSV injection vulnerability affecting credential exports. This attack class has been known for many years and was previously documented in Passbolt's security whitepaper. As a result of the audit and recommendations, Passbolt decided to phase out and ultimately disable cleartext CSV exports, favoring export formats that better preserve the confidentiality and integrity of sensitive data. Additional findings included username enumeration during account recovery, support for weak TLS 1.2 cipher suites, and recommendations to further harden browser extension permissions and Content Security Policy settings.

The findings reported by Quarkslab have either been addressed, incorporated into the product roadmap, or resulted in improvements to Passbolt's documentation and hardening guidance. You can read the summary below or consult the full audit report for detailed technical information.

Vulnerabilities

Medium - CSV Injection - Fixed in 5.10

Prior to version 5.10 (March 2026), it was possible to export CSV files containing data interpreted as formulas, which could then be executed on the user's machine by spreadsheet applications.

While escaping output is the conventional mitigation for this type of vulnerability, we opted for a different approach.

Our mitigation consists of disabling all CSV exports by default. As of version 5.10.0 of both the API and the browser extension, these export options are no longer exposed in the UI.

Administrators who require CSV export functionality can re-enable it via a server configuration. In that case, end users attempting to export CSV files are presented with a warning message explaining the risks, and are required to acknowledge it by checking a confirmation checkbox before proceeding. An external link is also provided to let users learn more about this type of attack.

We intentionally chose not to escape the exported data in order to preserve data integrity. Since we cannot anticipate how the exported data will be consumed, whether by spreadsheet software, a custom client, or another tool, and whether escaping would be handled correctly downstream, we want to guarantee that the exported data remains unchanged.

We consider the combination of the default disabled state and the mandatory user acknowledgment to be a sufficient mitigation for this risk.

Low - Username Enumeration - Fixed in 5.9

As mentioned in the report, the tested version allows email address enumeration through the account recovery form. This issue was fixed in API version 5.9.0 by applying the following recommended rules:

• The HTTP response code is now identical regardless of whether the user's email address exists or not.
• From the user's perspective, the displayed message is always the same.

There is one exception, however: when the self-registration feature is enabled (disabled by default), the HTTP response code will differ so that users can initiate their self-registration process.

We also took note of this observation and applied the same principle to the SCIM user synchronization process, which was not mentioned in the report. While response-based enumeration has been mitigated, a limited residual risk remains through timing-based side channels.

INFO - CSP Misconfiguration - Fixed in v5.10

The previous browser extension CSP configuration was overly permissive, relying on minimal declarations. This has been strengthened in browser extension version 5.10 by adopting a whitelist approach and explicitly specifying directives that lack fallback values.

Before the fix:

• Google Chrome: script-src: 'self'
• Firefox, Edge, Safari: script-src: 'self'; object-src: 'none'

After the fix (applied uniformly across all 4 supported browsers — Chrome, Firefox, Edge, and Safari):

default-src 'none'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https: http:; font-src 'self'; connect-src 'self' https: http:; form-action 'self' https:; frame-src 'self'; frame-ancestors 'self' https: http:; worker-src 'self'; base-uri 'none';

Here is a breakdown of each directive:

• default-src 'none' - Ensures that any undeclared *-src directives fall back to none, restricting all resource types by default.
• script-src 'self' - Restricts scripts to the extension itself (no change from the previous version).
• style-src 'self' 'unsafe-inline' - Allows styles from the extension and inline styles; unsafe-inline is currently required as some SVG files embed <style> tags.
• img-src 'self' data: https: http: - Allows images from the extension (self), remote avatars served by the API (https: and http:), and inline data URIs used by some SVGs (data:).
• font-src 'self' - Restricts font loading to the extension only.
• connect-src 'self' https: http: - Allows network requests from the extension itself and to the API.
• form-action 'self' https: - Allows form submissions to the extension and to HTTPS endpoints, which is required for integrations such as Duo MFA.
• frame-src 'self' - Restricts iframe origins to the extension itself, as iframes are the primary method used to render the extension UI.
• frame-ancestors 'self' https: http: - Restricts the protocols of origins allowed to embed the extension in an iframe; self is required for the quick access popup.
• worker-src 'self' - Restricts Web Workers to the extension only.
• base-uri 'none' - Disallows the use of <base> tags in page sources.

This is a first step in our CSP hardening roadmap. Further improvements are planned for upcoming versions.

INFO - Permissions Overreach - Disagree with Assessment

Admittedly, the list of permissions may appear extensive at first glance, but all of them are genuinely required. Moreover the clipboard access is requested in write-only mode. Details on why each permission is needed is available in the security whitepaper.