CVE-2025-55315

What it actually does

The vulnerability is an HTTP request/response smuggling flaw caused by inconsistent parsing of HTTP messages in ASP.NET Core components, including ASP.NET Core 10.0, 9.0, 8.0, and 2.3. When an application is deployed behind a reverse proxy, load balancer, gateway, or other intermediary, the front-end component and ASP.NET Core back end may disagree about where one HTTP request ends and the next begins. An authenticated network attacker can craft ambiguous HTTP requests that cause the back end to process attacker-controlled data as a separate request, potentially bypassing authentication or authorization controls, reaching protected endpoints, poisoning request routing, or interfering with other users' requests. The assigned severity is critical, with CVSS 9.9 and high EPSS probability, and exploit code is reported as available.

Why it matters to the business

Successful exploitation can let an attacker who already has some authorized access reach functionality or data they should not be allowed to access. For internet-facing ASP.NET Core services, APIs, identity-aware applications, and services behind reverse proxies, this can lead to account-level privilege boundary failures, unauthorized data access, fraudulent actions, service disruption, and loss of trust in access-control enforcement. Although it is not currently listed in CISA KEV and is not marked as ransomware-associated, the high severity, high EPSS score, availability of exploit code, and roughly 300 days since publication make remediation urgent, especially for externally exposed applications and shared hosting or multi-tenant architectures.

How an attack unfolds

An attacker first obtains valid access to an application or API, because the flaw is described as requiring an authorized attacker. They then identify an ASP.NET Core endpoint reachable over the network, commonly through a reverse proxy, CDN, API gateway, or load balancer. The attacker sends specially crafted HTTP traffic containing ambiguous framing, such as conflicting or malformed request-length indicators, header variations, or chunked-body edge cases. If the front-end component and ASP.NET Core back end interpret the request boundaries differently, part of the attacker's payload may be queued and processed by the back end as a second, smuggled request. That smuggled request can target endpoints or methods that the front end, proxy, or application security layer would normally block or require a different authorization context for. In some deployments, the attacker may chain repeated attempts to bypass security controls, poison downstream connections, interfere with another user's request on a reused connection, or invoke sensitive application behavior without passing the expected checks.

How to fix it

Upgrade affected ASP.NET Core runtimes, shared frameworks, SDKs, containers, and application dependencies to Microsoft patched releases for ASP.NET Core 10.0, 9.0, 8.0, and any still-deployed 2.3 components. For source builds of dotnet/aspnetcore, ensure the codebase includes the fix commit 6254f5ca64f85b90327592dff67ea6b2ec0262c6 or a later trusted upstream revision. Rebuild and redeploy applications after updating the runtime or base image; patching the host alone may not update self-contained deployments or container images. Where SUSE package metadata is applicable, update listed firebird/firebird-classic packages to 2.5.2.26539-15.1 or later. As defense in depth, normalize and strictly validate HTTP request framing at the edge, reject requests containing both Content-Length and Transfer-Encoding where not explicitly supported, reject duplicate or conflicting Content-Length headers, disable unsafe HTTP/1.1 connection reuse where necessary, and align proxy, gateway, and Kestrel request-size and transfer-encoding behavior. Prefer current supported ASP.NET Core LTS versions and remove unsupported legacy runtime deployments.

How to confirm the fix worked

Inventory all deployed ASP.NET Core applications, container images, base images, build agents, and hosts, then confirm the installed shared framework and runtime versions are patched. Use commands such as dotnet --info and dotnet --list-runtimes on hosts and inside containers, and inspect application manifests for self-contained runtime bundles. For source-based deployments, verify that the ASP.NET Core source revision includes commit 6254f5ca64f85b90327592dff67ea6b2ec0262c6 or a later fixed revision. Confirm that reverse proxies, API gateways, CDNs, and load balancers are configured to reject ambiguous HTTP/1.1 framing and that their behavior matches the back end. Run controlled request-smuggling validation in a non-production or approved test window using a qualified security test tool; the expected result after remediation is consistent rejection or safe handling of malformed, duplicate, conflicting, and obfuscated request framing. Review application access controls on sensitive endpoints to ensure they do not depend solely on front-end routing or proxy-layer filtering.

Typical attack path

1. Obtain or use an existing authenticated session or API credential for the target application.
2. Identify ASP.NET Core services exposed through an intermediary such as a reverse proxy, API gateway, CDN, or load balancer.
3. Probe HTTP parsing behavior using malformed, duplicated, conflicting, or obfuscated request-framing headers.
4. Determine whether the front-end component and ASP.NET Core back end disagree on request boundaries.
5. Send a crafted request that causes attacker-controlled bytes to be interpreted as a separate back-end request.
6. Target protected routes, privileged methods, internal-only paths, or security-filtered functionality with the smuggled request.
7. Repeat or tune payloads to bypass authentication, authorization, routing, or request validation controls.
8. Use any unauthorized access gained to read data, modify resources, perform actions as another security context, or disrupt service behavior.

How to detect it

Look for evidence of HTTP request smuggling attempts and unexplained authorization bypass activity. Relevant log sources include reverse proxy logs, CDN/WAF logs, API gateway logs, load balancer logs, ASP.NET Core/Kestrel application logs, authentication and authorization logs, endpoint access logs, and container ingress logs. Investigate requests from authenticated users that contain both Transfer-Encoding and Content-Length, duplicate Content-Length headers, unusual Transfer-Encoding values, malformed chunked bodies, unexpected bytes after request completion, abnormal 400/408/502/503 spikes, request parsing exceptions, and sequences where one connection appears to generate multiple unexpected back-end requests. Correlate front-end and back-end logs by timestamp, client IP, connection ID, request ID, and authenticated principal; mismatches where the proxy records one request but the application records additional or different requests are especially suspicious. Review access to protected endpoints that lacks expected authorization events, CSRF checks, route-level gateway logs, or normal navigation/API call patterns. Because request smuggling often leaves no fixed file artifact, detection depends on HTTP telemetry correlation and application behavior anomalies rather than static host indicators.

• Transfer-Encoding: chunked
• Content-Length: 0
• Transfer-Encoding: cow
• Transfer-Encoding : chunked
• Transfer-Encoding: chunked, chunked
• Content-Length: 0\r\nContent-Length:
• Transfer-Encoding: chunked\r\nContent-Length:
• Content-Length:\r\n Content-Length:
• 0\r\n\r\nGET /
• 0\r\n\r\nPOST /
• Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException
• BadHttpRequestException
• Unexpected end of request content
• Request body too large
• Invalid request line
• Invalid request headers
• The input string contains non-ASCII or null characters
• Connection processing ended abnormally
• Malformed request body
• duplicate Content-Length
• conflicting Content-Length
• CL.TE
• TE.CL

What your security team should do

• Prioritize internet-facing ASP.NET Core applications and APIs, especially those behind reverse proxies, API gateways, CDNs, or load balancers.
• Patch ASP.NET Core runtimes, SDKs, base container images, and self-contained application deployments; verify source builds include commit 6254f5ca64f85b90327592dff67ea6b2ec0262c6 or later.
• Treat this as urgent despite the absence of KEV listing because exploit code is available, CVSS is 9.9, and EPSS is high.
• Search logs for request-smuggling probes and anomalous authenticated access to protected endpoints before and after patching.
• Enforce edge-layer rejection of ambiguous HTTP requests, including conflicting Transfer-Encoding and Content-Length headers and duplicate Content-Length values.
• Review whether any sensitive routes rely on proxy-only controls and move critical authorization enforcement into the application where possible.
• Add regression tests for malformed HTTP framing in CI/CD or pre-production security testing for ASP.NET Core services.
• Rotate or invalidate sessions and API tokens for accounts showing suspicious request-smuggling behavior or unexplained access to restricted functionality.
• Monitor Microsoft, .NET, Linux distribution, and container image advisories for patched runtime versions and rebuild affected workloads promptly.