In 2025.2.0 and 2025.2.1 there has been security fixes that are published in the following Common Vulnerabilities and Exposures (CVEs):

• CVE-2025-51846: “Unbounded WebSocket Frame Flood Enables Remote Denial of Service (DoS)”. CVSS3.1: 7.5 (High)
• CVE-2026-26028: “Sanitizer Bypass in Diffmarked.js Allows Arbitrary HTML Injection and Potential XSS” (Cross-Site Scripting, blocked by our content security policy (CSP)). CVSS3.1: 6.1 (moderate)

In this blog post we will explain these security vulnerabilities in turn, explaining their impact and the measures we took to address them.

One of the vulnerabilities, CVE-2025-51846, was exploited against our flagship instance as part of a DoS attack on January 28th 2026 that led to a service outage. This blog post also serves as a post-mortem for this incident.

1. Frame flooding enabling Denial of Service

Context

Since we were taking part in the OpenDesk project, CryptPad code has been audited for security by Uni Systems at the request of the Bundesamt für Sicherheit in der Informationstechnik (BSI). This audit was part of an initiative for code analysis for open source software (CAOS, in German). We are thankful to them for that!

Most reported vulnerabilities did not fall in the scope of our threat model. However, one vulnerability was found to be serious enough to warrant a : CVE-2025-51846. If you are interested in more technical details, please see the full advisory.

In this post, we will explain what this vulnerability means, how it impacted us, and the changes we made, both in our code and in our way of dealing with security reports.

The vulnerability

CryptPad relies on websocket connections to exchange data between the client and the server, for instance to get your encrypted data for collaboration or the encrypted content of your drive.

However, these connections were not rate-limited in any way. This meant that it was possible to use them to repeatedly send over and over again some known websocket frames that would be accepted and processed by the server. Even if they have no effect, they still require some computing and keeping a connection open. It thus leads to ressource overload, effectively resulting in a denial-of-service attack.

To protect against such attacks, nginx (the web server we use) has rate-limiting features. We have now added the appropriate directives to our example configuration as well as the one we use in production for cryptpad.fr.

For instance administrators

If you are using CryptPad behind nginx with a variation of our nginx advanced configuration, please update it with our latest version as soon as possible.

The details of the changes can be seen in this commit.

Consequences

As we were slow to respond to this looming threat, cryptpad.fr was targeted by a distributed denial-of-service attack on January 28th 2026. The incident was resolved in under 3 hours. However, the server was already under high load from legitimate users, and we did not notice the issue immediately.

The fix has been included in our Winter fix release (2026.2.1). In line with the discussion between our team and the security researchers, we embargoed this disclosure for 90 days after the release to give instance administrators time to update their instances. However in this case, the reporter disputed the validity of the embargo as it was not written clearly in our security policy. The CVE was thus published on April 30th, which is 34 days after the 2024.2.1 release.

Our response

Consequently, we wanted to avoid putting instance administrators under the risk of a public vulnerability without having the time to upgrade their instances in the future. We also wanted to ensure that instances on our public list aren't exposed to attacks through known vulnerabilities.

To this end, we wrote a new security policy to:

• Explicitly state the length of the embargo period to protect third-party instances;
• Clearly list the channels available to report vulnerabilities to us;
• Explain the specificities of CryptPad and what falls into our threat model;
• Be transparent about the security processes that our team follows, and the verification steps on our code and external dependencies we also do on our side.

We hope that this new policy will improve the security practices around CryptPad, and make it easier for our team and community to build more secure software.

2. Sanitizer bypass

As stated in the introduction, the security advisory GHSA-g2g4-47gv-p72v describing CVE-2026-26028 has recently been published on GitHub.

We are thankful to user @ixSly on GitHub, for reporting it to us.

We use iframes in multiple ways in CryptPad, one of them is to embed external ressources (for example encrypted PDFs). As they are a common attack vector, the source of these iframes is sanitized in CryptPad to only allow authorized sources. However, we missed the possible use of the srcdoc attribute to inject arbitrary HTML in an iframe.

Fortunately, this does not lead to exploitable attacks, as CryptPad’s content-security policy (CSP) blocks it at the browser’s level. However, in order not to rely on CSPs for security, we fixed this issue by improving our sanitizer with the removal of iframes containing these attributes before rendering the page.