Loading story…
Researchers disclosed two vulnerabilities in the .NET libraries RestSharp and Refit that allowed CRLF header injection and HTTP request splitting through unsafe use of HttpHeaders.TryAddWithoutValidation. The issues, tracked as CVE-2024-45302 and CVE-2024-51501, affected APIs that accepted attacker-controlled header values, including RestSharp methods such as AddHeader, AddOrUpdateHeader, and AddDefaultHeader, as well as Refit's [Header] and [Authorize] attributes. Proof-of-concept testing showed that injected \r\n sequences could append unintended headers or create a second HTTP/1.1 request, with Apache logs capturing unexpected requests to /secret endpoints.
Microsoft's documentation for TryAddWithoutValidation states that the method validates header names but does not validate header values, and warns that untrusted input containing newline characters can cause application misbehavior and enable request smuggling-style attacks. The guidance recommends rejecting at least \r, \n, and \0 before using the API. Both library maintainers accepted the reports and released fixes after disclosure, while the researcher said large-scale searches across GitHub and NuGet found many uses of the method but only these two libraries produced confirmed exploitable cases.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
6 events from the most recent confirmed update back to the earliest known activity.
Microsoft's .NET documentation warned that HttpHeaders.TryAddWithoutValidation must not be used with untrusted values because malformed input, especially CR, LF, and null characters, can enable issues such as request smuggling. The guidance recommends validating inputs and rejecting those characters at minimum.
Binary Security published research detailing CRLF header injection and HTTP request splitting vulnerabilities in RestSharp and Refit, including proof-of-concept exploits and affected APIs. The disclosure states there was no confirmation of real-world exploitation or vulnerable downstream applications.
In January 2025, the researcher searched GitHub for public .cs files using TryAddWithoutValidation and found 10,368 hits, ultimately identifying 4,241 unique repositories after working around API result limits. The broader review, combined with decompiling about 5,000 public NuGet packages, produced only two interesting vulnerable libraries among 171 checked items.
In August 2024, the researcher reported CRLF header injection and request splitting issues affecting the RestSharp and Refit .NET libraries. The issues were later assigned CVE-2024-45302 for RestSharp and CVE-2024-51501 for Refit.
After accepting the August 2024 reports, RestSharp and Refit released fixes for the vulnerabilities in their libraries. The source does not provide a more specific date for the releases.
Binary Security's research began after observing that .NET's HttpHeaders.TryAddWithoutValidation validates header names but not header values, enabling CRLF-based header injection and HTTP/1.1 request splitting. The researcher demonstrated the behavior with a basic .NET HttpClient proof of concept and confirmed injected requests in Apache logs.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers documented multiple ways HTTP header injection can occur when applications place untrusted input into response headers, showing that obsolete line folding and encoding edge cases can turn filtered data into new headers. One documented path abused **Linear White Space (LWS)** permitted under `RFC 2616`, where folded header lines could be interpreted inconsistently by browsers; Internet Explorer through IE11 could treat a folded continuation line as a separate header, enabling response splitting and browser-side script execution with impact similar to cross-site scripting. Later guidance in `RFC 7230` deprecated this folding behavior and prohibited senders from emitting it in most cases. A separate case in the Java web server **Undertow** (`CVE-2018-1067`) showed how CR/LF filtering could be bypassed even when direct newline characters were blocked. Undertow validated Java `char` values before converting them to bytes, allowing attackers to use multibyte characters such as `U+560A` that truncated to `0x0A` during conversion and reintroduced a newline into the HTTP header stream. The flaw was fixed by checking for CR/LF after byte conversion, while broader mitigations across both cases include rejecting or sanitizing carriage return and line feed characters, avoiding validation before transformation, and relying on modern platform protections that enforce stricter header handling.
Aug 15, 2026
Microsoft has addressed a critical security vulnerability in the Kestrel web server component of ASP.NET Core, tracked as CVE-2025-55315, which received a CVSS severity score of 9.9—the highest ever assigned by Microsoft to a flaw in this framework. The vulnerability enables HTTP request smuggling, a technique where an attacker can embed a malicious request within a legitimate one, potentially bypassing authentication and other security controls. This flaw affects all currently supported versions of ASP.NET Core, including versions 8, 9, and 10, as well as the older ASP.NET Core 2.3 running on the Windows-only .NET Framework. According to Microsoft’s security advisory, the vulnerability allows authenticated attackers to exploit inconsistent HTTP request interpretation, leading to the bypass of security features over a network. Security program manager Barry Dorrans explained that a successful attack could allow an adversary to log in as a different user, circumvent cross-site request forgery (CSRF) protections, or perform injection attacks. The actual risk posed by this vulnerability is highly dependent on the specific application code and deployment configuration, with the most severe outcomes occurring in applications that do not properly validate or handle HTTP requests. Dorrans emphasized that while the vulnerability is serious, the likelihood of exploitation is reduced if applications are well-designed and if reverse proxies or gateways are used to filter out smuggled requests. The high CVSS score reflects the potential for a security feature bypass that changes the scope of access, rather than the likelihood of exploitation in all environments. Developers have sought clarification on what constitutes vulnerable application code, but Microsoft has indicated that any application performing authentication or access control based on HTTP requests could be at risk if not properly secured. Kestrel is widely used as the default web server for ASP.NET Core applications, both behind reverse proxies and as a direct-facing server, increasing the potential exposure. Microsoft’s patch addresses the underlying issue in Kestrel, and organizations are urged to apply updates promptly to mitigate the risk. The vulnerability highlights the importance of secure coding practices and the need for defense-in-depth measures, such as using reverse proxies to sanitize incoming requests. Security teams should review their ASP.NET Core deployments, especially those directly exposing Kestrel to the internet, to ensure they are not susceptible to request smuggling attacks. The incident underscores the evolving complexity of web application security and the critical role of timely patch management. Microsoft’s response demonstrates a commitment to transparency and rapid remediation for high-severity vulnerabilities in its ecosystem. Organizations leveraging ASP.NET Core should remain vigilant for further advisories and best practice recommendations from Microsoft and the broader security community.
Jun 29, 2026
A critical vulnerability in the Axios HTTP client library, tracked as **`CVE-2026-40175`**, allows attackers to turn polluted JavaScript object properties into malicious HTTP headers and abuse outbound requests for **SSRF**, **request smuggling**, and potential **remote code execution**. Researchers said the flaw stems from improper header handling in Axios’s HTTP adapter and unsafe config merging, which can let `Object.prototype` values containing CRLF characters be injected into requests. The issue can be chained with prototype pollution in other npm packages to target internal services, including the AWS EC2 metadata endpoint at `169.254.169.254`, potentially bypassing **IMDSv2** and exposing cloud credentials or broader infrastructure. A public proof-of-concept was released alongside disclosure, raising urgency for defenders even though active exploitation had not been confirmed at the time of reporting. The flaw affects Axios versions before **`1.13.2`**, while maintainers said **`1.15.0`** introduces strict header validation that blocks CRLF-based header injection; organizations were urged to upgrade and audit dependencies such as **`body-parser`**, **`qs`**, and **`minimist`** for prototype pollution paths. One report cited internet-wide estimates of more than **48,000** potentially exposed instances, underscoring the risk of unauthorized internal access and possible full cloud compromise.
Jun 29, 2026