How I Found the Worst ASP.NET Vulnerability — A $10K Bug (CVE-2025-55315)

Introduction

Earlier this year, I earned a $10,000 bounty from Microsoft after discovering a critical HTTP request smuggling vulnerability in ASP.NET Core’s Kestrel server (CVE-2025-55315). The vulnerability garnered significant media attention after Microsoft assigned it a CVSS score of 9.9, the highest severity rating ever assigned to an ASP.NET Core vulnerability.

This post walks through the vulnerability, how I found it, and discusses the severity rating.

Request Smuggling Recap

Introduction

This post walks through the vulnerability, how I found it, and discusses the severity rating.

Request Smuggling Recap

HTTP request smuggling is a type of vulnerability that exploits ambiguities in how servers determine request boundaries. When front-end and back-end servers parse requests differently, attackers can inject malicious requests that are processed in ways the developers did not intend. Examples of what these malicious requests can do include bypassing front-end security controls, hijacking user accounts, performing requests on behalf of victims, and poisoning the web server’s cache to serve malicious content.

For more details, see PortSwigger’s article.

Generally speaking, this is a systemic problem with HTTP/1.1 where minor parsing discrepancies become catastrophically exploitable.

Funky Chunks

My journey started with Jeppe’s excellent research on request smuggling via chunked transfer encoding extensions. His technique exposed a new class of request smuggling vulnerabilities due to how HTTP parsers handle chunk extensions inconsistently.

According to RFC 9112 section 7.1.1, chunk extension names must be valid token values, and RFC 9110 section 5.6.2 explicitly defines tokens as excluding all control characters, but many implementations accept lone control characters such as `\n` or `\r`.

Here is how each part of the system interprets the request:

Front-end interpretation:

– Interprets the `\n` after the semicolon as a line terminator

– Chunk 1: size `2`, body `xx`

– Chunk 2: size `45`

– The `GET /admin` request is hidden inside what the proxy perceives as the body of the second chunk

– Only sees one request to `/one`

Kestrel interpretation:

– Treats the `\n` as part of the chunk extension, not as a terminator

– Continues searching for the proper `\r\n` sequence

– The `45\r\n0\r\n\r\n` sequence is consumed as part of the first chunk’s extension and data

– The `GET /admin` request is interpreted as a separate, second pipelined request

This can lead to potential attacks such as:

Request Tunneling to Bypass Front-End Controls:

Attackers can smuggle requests to restricted endpoints that are blocked by WAFs or access control rules at the proxy layer. Since the proxy doesn’t recognize the smuggled request.

https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-bypass-front-end-security-controls

Request Hijacking:

An attacker can smuggle a request, causing the backend to append the next victim’s request (including cookies, authorization headers, and session tokens) to the attacker’s smuggled request body. The server then returns this sensitive data in the response, allowing credential theft or allowing the attacker to perform requests as the victim.

https://portswigger.net/web-security/request-smuggling/exploiting#capturing-other-users-requests

Cache Poisoning:

By smuggling requests that generate malicious responses, attackers can poison intermediate caches.

https://portswigger.net/web-security/request-smuggling/exploiting#using-http-request-smuggling-to-perform-web-cache-poisoning

My colleague, Wei Lin Ngo, pointed out that the vulnerability was likely in Kestrel’s chunk parsing implementation, specifically.

Source Code Analysis

The vulnerability existed in Kestrel’s `ParseExtension` method within the `Http1ChunkedEncodingMessageBody` class. The vulnerable code was searching only for the `\r` (carriage return) character when parsing chunk extensions:

“`csharp

SequencePosition? extensionCursorPosition = buffer.PositionOf(ByteCR);

“`

This meant that if a chunk extension contained a lone `\n` (line feed) character, Kestrel would treat it as part of the extension and continue searching for the `\r\n` sequence. However, many proxies interpret a lone `\n` as a line terminator, creating the parsing discrepancy needed for this type of attack.

The fix introduced proper validation by searching for both `\r` and `\n` characters and rejecting requests with unpaired line terminators:

“`csharp

extensionCursorPosition = buffer.PositionOfAny(ByteCR, ByteLF);

if (suffixSpan[0] == ByteCR && suffixSpan[1] == ByteLF)

{

// Valid CRLF sequence

}

else

{

// Invalid – reject the request

KestrelBadHttpRequestException.Throw(RequestRejectionReason.BadChunkExtension);

}

“`

The patch also added a compatibility flag (`InsecureChunkedParsing`) to allow organizations to temporarily revert to the old behavior if needed.

Understanding the 9.9 CVSS Score

When Microsoft released CVE-2025-55315, the 9.9 severity rating led to some discussion in the community. The vulnerability made it to the front page of Hacker News, where many users questioned whether such a high severity score was appropriate.

Broadly speaking, it’s difficult to rate severities for library vulnerabilities since it’s impossible to triage every single application that uses them. CVSS was designed for singular systems, not reusable components, where impact varies dramatically based on implementation. Microsoft scored based on worst-case scenarios for applications built on Kestrel.

The high severity rating was primarily about signaling urgency to downstream users. With the vulnerability present for years across multiple ASP.NET Core versions, the conservative scoring helped ensure organizations prioritized patching quickly, regardless of their specific risk profile.

It’s also important to note that request smuggling vulnerabilities are highly situational, and their exploitability depends on the entire web architecture, including the specific proxy/load balancer configuration, HTTP protocol version, connection pooling configuration, and backend application logic.

Community Impact

Burp Suite Integration

Following this discovery, I contributed to PortSwigger’s official HTTP Request Smuggler extension for Burp Suite. The latest version (v3.0.2) now includes detection capabilities for request smuggling via chunked transfer encoding extensions, making it easier for security researchers to identify these issues.

Chariot Detection

Our security product, Chariot ,,) had already implemented detection for this class of vulnerabilities well before the CVE disclosure.

Timeline

– **Initial Discovery**: June 19th, 2025

– **Responsible Disclosure to Microsoft**: June 22, 2025

– **Vulnerability Confirmed by Microsoft**: July 18, 2025

– **Bounty Awarded**: July 21, 2025 ($10,000)

– **CVE Assigned**: CVE-2025-55315

– **Patch Released**: October 14, 2025

– **Public Disclosure**: October 14, 2025

Conclusion

This vulnerability demonstrates how seemingly minor implementation differences in HTTP parsing can lead to critical security issues. Credit to Jeppe for the initial research that inspired this discovery, and thanks to Microsoft’s security team for their responsive handling of the disclosure.

However, this finding is symptomatic of a larger problem in the HTTP/1.1 protocol itself. As James Kettle recently demonstrated in his research ,,) the protocol’s weak request boundaries and ambiguous message length specifications mean that minor implementation bugs often lead to severe security consequences.