On CVE-2025-55315: Security Assessment

Automatic Pre-Emption: Why the Malicious Request Failed (Details the result of the attempted exploit)

A few weeks ago, a new vulnerability tracked as CVE-2025-55315 was disclosed in .NET across multiple versions with a critical 9.9 severity score. This vulnerability allows unauthorized users to send requests to ASP.NET Core web applications by smuggling them right after other requests, bypassing the platform’s authorization mechanisms. As you may know, RavenDB is built on .NET. To ensure your databases are secure, we investigated this vulnerability and assessed the impact on your database server. Is this a problem for RavenDB users?

The short answer to this question is: No, it cannot affect your database because of how RavenDB handles authentication and authorization.

Let’s explore the vulnerability and RavenDB security design to understand why our database isn’t affected.

Details

Let’s start with why CVE-2025-55315 is considered a 9.9 severity score. It is mainly because:

• It is remotely exploitable over the network.
  
• It is easy to exploit with low attack complexity and no user interaction required.
  
• It requires the attacker to have low privileges.
  
• It leads to a high impact on Confidentiality and Integrity,
  

CVE-2025-55315 is used to smuggle malicious requests within a request tandem by exploiting inconsistencies in request parsing, when using chunked requests, allowing for unauthorized access to endpoints.

For example, in RavenDB, this exploit would try to use an unsecured (by design) endpoint, like:

GET /setup/alive

And try to tag along an additional request to another, this time secured, endpoint – e.g. to delete a database:

DELETE /admin/database?name=precious_data

By leveraging the hack, a threat actor would be able to call any secured API endpoint carelessly.

But it turns out, trying to run the exploit on the RavenDB server, you get the following result:

RavenDB server response when running CVE-55315 exploit, presents 2 endpoints being called, yet both were ultimately properly authenticated.

As you can see, the malicious request didn’t pass – it returned a 403 Forbidden because it lacked a certificate. Why didn’t it work?

RavenDB Security Model

Let’s analyze how RavenDB handles incoming HTTP requests. Using mutual TLS, both the server and the client are validated using certificates at the connection stage.

This happens for every connection to the server, confirming whether an actor was granted access. If there’s no valid certificate on the TLS layer, the connection (with the request in the payload) is rejected.

An attacker might try to attach another request to request not requiring permissions trying to bypass security. RavenDB retrieves identity from the supplied client certificate from the TLS connection context and stores it in memory and then runs authorization checks on every request.

Since RavenDB performs its own authorization in the request handler rather than using ASP.NET Core security middleware, any unexpected or unauthorized requests are stopped before reaching the endpoint.

In short, our security model’s foundational differences in connection establishment provided automatic pre-emption against this vulnerability.

Additional reading resources:

Official MS advisory: https://github.com/dotnet/aspnetcore/issues/64033

NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-55315