CVE-2025-55315: Critical Request Smuggling Vulnerability Exposes ASP.NET Core and Tenable Identity Systems

Quick Facts


CVE ID	CVE-2025-55315
CVSS Score	9.9 (Critical) – the most severe ASP.NET vulnerability seen to date
Attack Vector	Network-based, low complexity, requires low-privilege authentication
Impact	Privilege escalation, credential theft, security control bypass
Release Date	October 14, 2025
Affected Products	ASP.NET Core 8.x, 9.x, 10.x and Tenable Identity Exposure versions prior to 3.93.4

What’s the Issue?

Microsoft has patched what is arguably one of the most serious vulnerabilities ever discovered in ASP.NET. The flaw sits in how the Kestrel web server processes HTTP requests and allows authenticated attackers to smuggle malicious requests past upstream security controls.

The problem appears when traffic is routed through a reverse proxy (such as Nginx, IIS, Azure Front Door, or similar) before reaching an ASP.NET Core application. Both the proxy and the backend server must agree on where one HTTP request ends and the next begins. HTTP provides two mechanisms for this: the Content-Length header and the Transfer-Encoding header.

When those headers conflict, the proxy and backend may interpret the request differently. The proxy could believe it has blocked a malicious request, while the backend still processes it. That desynchronization is the foundation of HTTP request smuggling.

What makes this vulnerability particularly dangerous is how effectively it bypasses security layers. Authentication checks, CSRF protections, WAF rules, and access controls can all be skipped. The attacker does not need advanced exploitation skills—anyone with basic network access or a low-privilege account can potentially abuse it.

How the Attack Works

At its core, the issue is deceptively simple.

Imagine two security guards inspecting the same package. One checks weight, the other counts items. If the labels don’t line up, they may disagree on what’s actually inside.

That’s exactly what happens here. When a request includes both a Content-Length header and a Transfer-Encoding: chunked header, the proxy and the Kestrel backend may disagree on where the request boundary lies. An attacker exploits this mismatch by crafting a request that:

Appears harmless to the proxy when interpreted via Content-Length
Is parsed differently by Kestrel using Transfer-Encoding
Leaves extra data that becomes a hidden second request

Example Payload

POST /legitimate HTTP/1.1
Content-Length: 4
Transfer-Encoding: chunked

1e
GET /admin HTTP/1.1
Host: target.com

0

In this case, the proxy reads four bytes of body data and forwards the request. Kestrel, however, interprets the chunked encoding, sees 1e (hex for 30), reads thirty bytes, and discovers a complete GET /admin request embedded in the payload. That request is then processed—completely bypassing the proxy’s controls.

The root cause is insufficiently strict validation of request boundaries in Kestrel. Attackers can further obscure their intent by inserting tabs, vertical tabs, or unusual whitespace into headers, making detection even harder.

What an Attacker Can Do

Successful exploitation opens the door to serious impact:

Credential theft – Capture session tokens, authentication headers, or other sensitive credentials
Privilege escalation – Reach administrative endpoints that should be inaccessible
CSRF bypass – Execute actions without valid CSRF tokens
Data manipulation – Modify records, configurations, or stored data
Internal access – Reach internal APIs or services not exposed externally
Tenable-specific impact – Access identity exposure data, credential discovery results, or breach intelligence reserved for privileged roles

The main limitation is that the attacker needs either valid credentials or network-level access. While this prevents drive-by exploitation, it makes insider threats, compromised accounts, and internal attackers especially dangerous.

What Gets Compromised

Data Exposure

Attackers may gain access to login credentials, session tokens, API keys, user records, and any sensitive data handled by the application. In Tenable Identity Exposure environments, this could include credential repositories, exposure analysis data, and breach intelligence shown only to trusted users.

Data Tampering

An attacker can alter stored data, change system configurations, inject malicious content, or manipulate audit logs. A common scenario would be promoting a standard account to administrator or hiding traces of abuse.

Service Disruption

While availability is not the primary risk, attackers may still cause crashes or resource exhaustion. The real concern remains confidentiality and integrity.

Real-World Attack Scenarios

Scenario 1: Insider Abuse
A user with legitimate but limited access smuggles requests to reach admin endpoints, downloading sensitive identity exposure data or changing access policies.

Scenario 2: Compromised Credentials
An attacker logs in with stolen user credentials, then escalates privileges via request smuggling without triggering standard alerts.

Scenario 3: Lateral Movement
An attacker already inside the corporate network bypasses WAF protections to reach internal identity or credential management APIs.

Scenario 4: Credential Theft
By carefully positioning smuggled requests, the attacker causes the server to leak another user’s session token, enabling account takeover.

Scenario 5: CSRF Bypass in Tenable
Unauthorized policy changes are executed by smuggling requests that avoid CSRF validation, weakening identity security across the organization.

Who’s Affected and How Exploitation Happens

Exploitation Requirements

Network access to the target application
Valid credentials or access to a compromised account
A vulnerable ASP.NET Core version (8.x prior to 8.0.21, 9.x prior to 9.0.10, or early 10.x builds)
An application with meaningful access controls or sensitive data

Typical Attack Flow

Obtain low-privilege access
Craft an HTTP request with conflicting headers
Embed a second request in the request body
Send it through the proxy shown to the backend
Let the proxy block the visible request
Allow the backend to process the smuggled one
Receive results in a later response on the same connection

Public proof-of-concept tools are already available, making exploitation straightforward once the concept is understood. HeroDevs has also released a safe testing tool to confirm whether a .NET build is vulnerable.

Systems at Risk

ASP.NET Core 8.0 (prior to 8.0.21)
ASP.NET Core 9.0 (prior to 9.0.10)
ASP.NET Core 10.0 (before fixes)
Tenable Identity Exposure (prior to 3.93.4)
Custom .NET applications using vulnerable Kestrel packages
IIS, Docker, Kubernetes, and cloud-hosted .NET deployments
Legacy .NET 6 environments (unsupported and still vulnerable)

What Needs to Be Patched

Microsoft Products (High Priority)

ASP.NET Core 8.0 → upgrade to 8.0.21 or later
ASP.NET Core 9.0 → upgrade to 9.0.10 or later
ASP.NET Core 10.0 → fixed in RC and later builds
Kestrel 2.x → update to version 2.3.6 or newer

Tenable Products (High Priority)

Tenable Identity Exposure → update to version 3.93.4 or later

Who Should Act Immediately

Organizations using Tenable Identity Exposure
Any production ASP.NET Core deployment
Cloud-hosted .NET applications
On-premises IIS deployments
Containerized .NET workloads
Teams still running .NET 6

How to Detect Exploitation

Log Indicators to Watch

Requests containing both Content-Length and Transfer-Encoding
Obfuscated Transfer-Encoding values with tabs or unusual spacing
Request bodies that contain full HTTP methods or paths
Low-privilege users accessing admin endpoints
Abnormally long request processing times
Response mismatches on the same connection (403 followed by 200)

Where to Look

Web server logs
Reverse proxy logs
Application logs
WAF and security appliance logs
Network packet captures

Some attacks may leave very subtle traces, making correlation and pattern analysis essential.

SIEM Considerations

Ensure visibility into:

Full request headers
Response codes and sizes
Request timing and connection reuse

Correlate:

Failed authentication followed by admin access
Rapid endpoint switching
Privilege mismatches
Off-hours activity

Remediation Guidance

There’s no realistic alternative to patching. Temporary workarounds help reduce risk but should not delay updates.

Download patches from official sources only:

Microsoft: https://dotnet.microsoft.com/download/dotnet

.NET 8: Get version 8.0.21 or newer
.NET 9: Get version 9.0.10 or newer
.NET 10: Already fixed in RC builds

Tenable: https://www.tenable.com/security/tns-2025-22

Tenable Identity Exposure: 3.93.4 or newer

How to patch depends on how you deploy:

If using a shared .NET runtime on servers (most common):

Stop your app
Install the new .NET runtime
Restart your app
Done—all apps on that server benefit from the fix

If running self-contained apps:

Update your build environment to the new SDK
Recompile your application
Deploy the new binaries
Restart the app

If using Docker/Kubernetes:

Update your base image (e.g., mcr.microsoft.com/dotnet/aspnet:8.0)
Rebuild your container images
Push to your registry
Roll out updates using your deployment system

If using the old Kestrel 2.x package directly:

Update Microsoft.AspNetCore.Server.Kestrel.Core to 2.3.6 in your project file
Recompile
Deploy

Verify using run dotnet --info or the HeroDevs validation tool.

MITRE ATT&CK Mapping

This vulnerability aligns with multiple ATT&CK techniques:

Initial Access: T1190
Valid Accounts: T1078
Defense Evasion: T1562
Privilege Escalation: T1548
Credential Access: T1134, T1187
Discovery: T1087, T1526
Exfiltration: T1041, T1020

The consistent theme is defense evasion combined with privilege escalation and credential theft.

Temporary Mitigations (If You Can’t Patch Immediately)

Proxy/WAF Controls

Reject requests with both headers
Strip Transfer-Encoding when possible
Enforce strict request validation
Disable HTTP/1.1 keep-alive

Application-Level Check

app.Use(async (context, next) => {
    var req = context.Request;
    if (req.Headers.ContainsKey("Content-Length") &&
        req.Headers.ContainsKey("Transfer-Encoding") &&
        !req.Headers["Transfer-Encoding"].ToString()
            .Equals("identity", StringComparison.OrdinalIgnoreCase))
    {
        context.Response.StatusCode = 400;
        await context.Response.WriteAsync("Bad Request");
        return;
    }
    await next();
});

These are short-term risk reducers—not replacements for patching.

Post-Patch Actions

After patching:

Verify runtime versions regularly
Continue monitoring for smuggling attempts
Prevent configuration drift

If compromise is suspected:

Review access logs
Revoke credentials
Isolate affected systems
Reset passwords
Perform forensic analysis

Final Takeaway

This vulnerability is as serious as its 9.9 CVSS score suggests. It affects widely deployed infrastructure and enables attackers to bypass fundamental security controls with alarming ease. Fortunately, remediation is straightforward: update your .NET runtime and Tenable installations.

Treat this as a Priority 1 issue. If you rely on ASP.NET Core in production, patches should be deployed in days—not weeks.

For Detection Rules click: https://cyberp1.com/cve-2025-55315-detection-rules-and-siem-queries-for-http-request-smuggling/