CVE-2025-55315: Understanding ‘Funky Chunks’ and Why Your Organisation Needs to Act Now

The image shows a charming set of matryoshka dolls, which are traditionally Russian nesting dolls. There are three dolls in the foreground and one larger doll in the background. Each doll is painted with vibrant colors and patterns, and they all feature traditional clothing, suggesting a cultural theme. They seem to be placed on a flat surface, possibly a table or shelf, and in front of them, there appears to be a book with a cover that features what looks like a character resembling the dolls. The background is blurred but suggests an indoor setting, possibly a room with some bookshelves or a similar display.

On 14th October 2025, Microsoft released security updates addressing CVE-2025-55315, a vulnerability in ASP .NET Core that enables HTTP request smuggling. Microsoft assigned this vulnerability a CVSS score of 9.9, representing one of the highest severity ratings they have ever issued. However, this is not merely a .NET problem; it exploits fundamental features of the HTTP/1.1 protocol that affect multiple web frameworks and server implementations.

This CVE is rated with a CVSS score of 9.9. That is 9.9 out of ten. This is basically the next the most severe CVE rating a CVE could achieve, which means we need to take notice.

If your organisation develops or maintains web applications, regardless of the technology stack, this vulnerability demands your immediate attention.

What Is CVE-2025-55315?

CVE-2025-55315 is a vulnerability that allows HTTP request smuggling, exploiting inconsistencies in how different components parse HTTP requests. Informally known as “Funky Chunks”, this vulnerability exploits ambiguous chunk line terminators in HTTP/1.1’s chunked transfer encoding mechanism.

The vulnerability affects applications using HTTP/1.0 and HTTP/1.1 protocols. HTTP/2 and HTTP/3 implementations are not vulnerable as they use different data streaming mechanisms.

ℹī¸ Note

HTTP request smuggling is not a new concept; it was first documented in 2005. However, this particular variant exploiting chunk extensions had not been identified until recently.

Why Should Decision Makers Care?

The Severity Rating Reflects Real-World Risk

The 9.9 score reflects the importance of promptly addressing this issue, which involves a security feature bypass that can influence how applications enforce authentication and authorization. Applying the patch ensures these protections remain strong.

The vulnerability could allow an attacker to craft a request that hides another request inside it, potentially enabling privilege escalation or request manipulation. This is not theoretical risk; the severity rating accounts for the most severe potential impact to encourage timely updates.

Technology-Agnostic Implications

💭 Consider the following: if your organisation uses web frameworks, reverse proxies, load balancers, or content delivery networks (CDNs), you are potentially affected regardless of your primary technology stack.

This vulnerability was given a CVSS score of 9.9 out of 10, which you know, sounds pretty bad! Request smuggling allows an attacker to hide an extra request inside another, and what that hidden request can do is very application specific.

Confirmed vulnerable implementations include:

Proxies and Load Balancers:

  • Apache Traffic Server (CVE-2024-53868)
  • Google Classic Application Load Balancer (awarded a $15,000 bounty)
  • pound

Web Servers and Frameworks:

ℹī¸ ⚠ī¸ Critical Point:

Many HTTP implementations do not strictly adhere to the chunk extension specification because these features are rarely used, leading to lenient parsing that creates exploitable discrepancies.

Understanding the Technical Mechanism

HTTP request smuggling exploits differences between how proxy servers and backend servers parse HTTP requests, where an ambiguous request appears as one request to the proxy but two separate requests to the backend server.

The traditional request smuggling technique involved conflicts between Content-Length and Transfer-Encoding headers. However, CVE-2025-55315 differs fundamentally from conventional request smuggling vulnerabilities in that it does not rely on confusion between these headers; instead, it exploits chunk extensions which can legally be forwarded.

The Chunk Extension Vulnerability

Chunk extensions are optional features in HTTP/1.1 that allow attaching metadata to individual chunks in chunked transfer encoding, but no HTTP implementation makes any meaningful use of them.

The vulnerability arises because:

  1. HTTP parsers simply consume chunk extensions and discard the contents
  2. Most HTTP implementations do not strictly adhere to the chunk extension specification because the contents are discarded anyway
  3. Different parsers handle invalid line terminators (such as lone \n characters) differently; some treat them as valid line endings, others ignore them, and only correct implementations reject them

This parsing discrepancy enables attackers to construct ambiguous HTTP requests where a proxy sees one request whilst the backend server interprets the same data as two separate requests.

What Attackers Can Achieve

Depending on how your application processes requests, this vulnerability could enable privilege escalation or request manipulation. The potential impacts include:

✅ Bypassing Authentication Controls: Attackers can smuggle requests that appear to have already been authenticated by the proxy

✅ Privilege Escalation: Smuggled login requests can elevate privileges when applications trust headers added by proxies

✅ Server-Side Request Forgery (SSRF): Smuggled internal API calls can access internal endpoints not meant to be publicly accessible

✅ Session Hijacking: Smuggled requests can bypass CSRF token validation

✅ Data Exfiltration: Attackers can capture and exfiltrate authentication credentials or other data from other users’ requests

✅ Code Injection: Smuggled injection payloads can achieve code execution if input sanitisation has gaps

ℹī¸ Warning

Request smuggling can be exploited even on sites not vulnerable to cross-site scripting; simply having functionality that displays user-provided data can be sufficient to steal credentials from other users.

Determining Your Risk Exposure: Are Your Applications Vulnerable?

The vulnerability exists in the web framework, but exploitation depends on how your application handles requests. Your applications could be impacted if they:

  • Parse raw requests manually
  • Rely on headers for security decisions
  • Skip validation based on request structure
  • Read, manipulate, or forward request streams directly rather than relying on built-in web framework features

The Proxy Consideration

💭 Many organisations assume they are safe because they do not use proxies. However, request smuggling vulnerabilities can apply even without explicitly using a proxy if your application reads or manipulates request streams.

Common scenarios that create vulnerability include:

  • Reverse proxies (nginx, Apache, cloud load balancers, ASP .NET Core’s Kestrel)
  • Content Delivery Networks (CDNs)
  • Web Application Firewalls (WAFs)
  • API gateways
  • Service meshes
  • Any application code that processes HTTP request bodies directly

The Security Scanner Blind Spot

ℹī¸ ⚠ī¸ Critical Warning for Security Teams:

If you rely on automated CVE scanning tools in your CI/CD pipelines or endpoint management systems, you must understand a significant limitation that could provide a false sense of security.

So those CVE scanning tools in your CI/CD system or your endpoint management tooling are not going to detect that this CVE is present if you have vulnerable versions of .NET 6 or 7 running and installed. You know, it could give you a false sense of security after running that report, say, ‘oh, there’s no CVEs here.’ Your scanner is not going to report the CVE in .NET 6 because the CVE doesn’t have 6 listed in the affected versions.

Why Security Scanners May Miss This Vulnerability

The official CVE-2025-55315 advisory only lists the affected versions of .NET 8, 9, and 10 because these are the only versions that received patches from Microsoft. However, as confirmed through independent security research, the vulnerability affects all versions of ASP .NET Core dating back to at least .NET Core 3.0.

This creates a dangerous situation where:

✅ Scanners will correctly identify: .NET 8, 9, and 10 applications that have not been patched

✅ Scanners will not identify: .NET Core 3.0, .NET Core 3.1, .NET 5, .NET 6, and .NET 7 applications, even though these versions are equally vulnerable

Because of this, it is imperative that you upgrade to a version of .NET that receives active support from Microsoft. At the time of publishing, this includes versions 8, 9, and 10 only.

ℹī¸ Note

While .NET 6 is not supported by Microsoft, it is supported by the .NET Never Ending support product from HeroDevs.

If you are running an earlier version of .NET, now is the time to upgrade.

The False Sense of Security

Organisations running vulnerability scans may receive reports showing “no known CVEs” for their legacy applications, leading decision makers to believe their systems are secure. In reality, these applications are vulnerable but simply not detected by the scanning tools.

💭 Consider this scenario: Your security team runs a comprehensive vulnerability scan across your infrastructure. The report shows your .NET 6 applications have no critical vulnerabilities. Meanwhile, those same applications are susceptible to HTTP request smuggling attacks that could enable privilege escalation, data theft, and security control bypass.

What This Means for Your Organisation

  1. Manual Verification Required: You cannot rely solely on automated scanning tools to identify exposure to CVE-2025-55315
  2. Inventory is Critical: You must maintain an accurate inventory of all framework versions in use across your organisation
  3. Assume Vulnerability: If you are running any version of ASP .NET Core (including all .NET Core and .NET 5-7 versions), assume you are vulnerable until proven otherwise
  4. Proactive Assessment: Conduct manual reviews of your technology stack rather than waiting for security scanners to flag the issue
  5. Communication Gap: Ensure that security teams, development teams, and management understand this limitation in their security tooling

The Exploitation Timeline

HTTP smuggling is not a new concept. It has been discussed since the early 2000s. This particular exploit using malformed chunking has been highlighted recently, and as I mentioned affects other ecosystems. So this is a known vector for attack on web-based applications and network services. So it’s very likely this is actively happening.

ℹī¸ ⚠ī¸ Urgent Consideration:

The vulnerability was documented in June 2025, with black-box detection methods published that can identify vulnerable combinations of servers and proxies. Malicious actors have had months to develop exploits.

Whilst there is no confirmed evidence of active exploitation in the wild, the publication of detailed exploitation techniques means that:

  1. Automated scanning tools likely already exist or are being developed
  2. The vulnerability may already be incorporated into penetration testing frameworks such as Metasploit
  3. Increased media coverage brings more attention from malicious actors

There’s going to be tools, you know, open source tools that test for this. You know, if there’s not a tool in Metasploit already, there probably will be very soon, you know. So there will be malicious actors scanning for this vulnerability. You know, just bulk scanning IP addresses, trying to find, you know, what they can slip past.

Required Actions for Decision Makers

Immediate Steps (Within 48 Hours)

  1. Inventory Your Technology Stack

    • Document all web frameworks and versions in production
    • Identify all proxies, load balancers, and CDNs in your infrastructure
    • Note any custom request handling or proxy logic in your applications

  2. Review Security Advisories

    • Check vendor security bulletins for your specific technology stack
    • Identify available patches and update schedules
    • Document any components that will not receive patches

  3. Assess Your Exposure

    • Review your application’s request handling logic, especially around authentication, authorisation, and input validation
    • Identify applications that handle sensitive data or regulated information
    • Prioritise applications with the highest business impact

Short-Term Actions (Within One Week)

  1. Apply Security Updates
    • Apply the latest security updates for your web frameworks and server software
    • For .NET applications: update to .NET 8.0.21, .NET 9.0.10, or .NET 10.0.0-rc2 as appropriate
    • Test updates in non-production environments first
    • Schedule maintenance windows for production deployments

ℹī¸ NOTE

This is your excuse to push for time during each sprint to check for CVEs and updates to your web frameworks.

  1. Verify Proxy Configurations

    • Confirm that proxies normalise requests and detect smuggling attempts
    • Review proxy logs for suspicious request patterns
    • Enable additional logging if available

  2. Implement Monitoring

    • Monitor for unusual request patterns in logs and telemetry
    • Set up alerts for potential request smuggling attempts
    • Document baseline behaviour for comparison

Medium-Term Actions (Within One Month)

  1. Security Review

    • Conduct penetration testing specifically for request smuggling vulnerabilities
    • Review application architecture for request handling patterns
    • Consider engaging security specialists if internal expertise is limited

  2. Infrastructure Hardening

    • Where possible, enforce HTTP/2 or HTTP/3 protocols (these are not vulnerable)
    • Implement defence-in-depth strategies
    • Validate baseline security configurations to ensure applications do not skip critical checks based on request structure

  3. Vendor Management

    • For cloud-hosted applications, confirm mitigation status with your provider
    • Review SLAs and security update procedures with vendors
    • Document any legacy systems that cannot be patched

Special Considerations for Legacy Systems

This vulnerability affects basically all versions of ASP .NET Core. I’ve personally tested down to .NET Core 3.0 and I can confirm that the vulnerability is there and there are no patches coming for you. The best thing to do is to update to a supported version of .NET.

ℹī¸ ⚠ī¸ Critical Warning:

If you are running ASP .NET Core on .NET Core 3.0, .NET Core 3.1, .NET 5, .NET 6, or .NET 7, you are vulnerable and there are no patches available from Microsoft. These frameworks have reached end-of-life and will not receive security updates from Microsoft.

Options for legacy systems include:

  1. Immediate Migration: Upgrade to supported framework versions (strongly recommended)
  2. Proxy-Level Protection: Ensure you have a patched proxy that blocks ambiguous requests before they reach your application
  3. Extended Support: Consider third-party support providers such as HeroDevs for critical systems that cannot be immediately upgraded
  4. Protocol Restriction: Configure servers to only accept HTTP/2 or HTTP/3, though this may break compatibility with older clients

Questions for Your Technical Leadership

As a decision maker, consider asking your technical teams the following questions:

  1. Have we completed an inventory of all web frameworks and versions in our production environment?
  2. Which of our applications handle authentication, authorisation, or sensitive data?
  3. What is our current patching schedule, and can we expedite updates for this vulnerability?
  4. Do we have any legacy systems that cannot receive security updates?
  5. Have we verified the security status of our cloud providers, CDNs, and third-party services?
  6. What monitoring and detection capabilities do we have for request smuggling attacks?
  7. When was our last security penetration test, and should we schedule one specifically for this vulnerability?

The Broader Security Context

This vulnerability highlights several important considerations for organisational security:

The Hidden Risk of ‘Unused’ Features

There is a standard in HTTP/1 that allows for what we call chunk extensions. Another thing to know is that these chunks have within them a section for metadata. Now, why would HTTP requests that contain serialised binary data have a section for metadata? There’s no reason for it to. It was part of the specification. It was a thought that there may be a use for this eventually, that just never materialised. And that is where the issue with the CVE lies.

Chunk extensions are an optional feature that no HTTP implementation makes meaningful use of; servers ignore them and clients don’t send them. Yet this "useless" feature created one of the most severe vulnerabilities in recent memory.

💭 Reflect on your own systems: what other rarely-used protocol features might harbour similar risks?

The Complexity of Modern Web Architectures

In environments where proxies are chained with different purposes, a chunk-normalising proxy with parsing flaws could still be exploitable if another proxy further up the chain is affected by the complementary parsing flaw.

Modern applications often involve multiple layers of infrastructure, each potentially introducing vulnerability. Defence-in-depth strategies become critical when any single component can compromise the entire system.

The Technology-Agnostic Nature of Vulnerabilities

Whilst this vulnerability gained prominence through Microsoft’s disclosure, it affects implementations across programming languages and frameworks. Security is not solved by choosing the “right” technology; it requires ongoing vigilance, prompt patching, and architectural considerations.

Conclusion

CVE-2025-55315 represents a significant security risk to organisations running web applications. The vulnerability’s high severity rating reflects genuine potential for exploitation, and the publication of detailed attack techniques means that malicious actors now have the knowledge and tools to attempt exploitation.

The implications of this vulnerability are so wide-ranging, depending on how your application is constructed, and there’s no way for Microsoft or other actors in the .NET community to tell you, ‘hey, this application is vulnerable to this. Like this is how this can happen.’ But it’s possible. And it’s the unknown that makes this particularly particularly scary.

Decision makers must act decisively:

  • ✅ Assess your exposure immediately
  • ✅ Apply available security updates as a priority
  • ✅ Verify the security posture of your infrastructure components
  • ✅ Implement monitoring and detection capabilities
  • ✅ Plan for long-term remediation of any systems that cannot be immediately patched

The good news is that patches are available for most modern frameworks, and protective measures can be implemented. The critical factor is time; the longer systems remain unpatched, the greater the risk of exploitation.

If your organisation requires assistance in assessing vulnerability exposure, implementing security updates, or developing a comprehensive remediation strategy, RJJ Software provides strategic technology consultation services to help organisations navigate complex security challenges.

Additional Resources

For those seeking more detailed technical information:

The Modern .NET Show has also published an interview with security researcher Hayden Barnes discussing this vulnerability in detail: Hayden Barnes and CVE-2025-55315

If you have concerns about your organisation’s exposure to CVE-2025-55315 or require assistance with security assessments and remediation, please contact RJJ Software to discuss how our Fractional CTO and strategic technology consultation services can help.