A recently published security advisory has identified a Carriage Return Line Feed (CRLF) injection vulnerability in the HTTP header processing logic of Gakido, a library developed under the HappyHackingSpace vendor. This flaw, tracked as RO-26-005 and assigned CVE-2026-24489, affects versions of Gakido prior to v0.1.1-1bc6019 and has been rated with medium severity due to its potential impact on HTTP request integrity and downstream application behavior.
What is the Vulnerability?
At its core, this vulnerability allows attackers to inject unexpected content into HTTP requests by exploiting insufficient sanitization of user-controlled header values. Specifically:
- HTTP headers supplied by the user are not properly cleansed of control characters prior to being sent.
- Characters such as
\r\n(CRLF),\n(LF alone), and even null bytes (\x00) can be inserted into header names or values. - When processed by Gakido’s internal logic, these characters can break the intended structure of headers and create new, malicious headers that were never intended by the original request.
The problem was localized to a single part of the library — the canonicalize_headers() function inside gakido/headers.py — which did not filter out dangerous sequences before constructing the outgoing HTTP request.
Why This Matters
CRLF injection vulnerabilities, while sometimes subtle, can be potent when misused:
- HTTP Header Injection: Attackers can add arbitrary headers to legitimate requests, potentially influencing how intermediate services or backends interpret the request.
- Response Splitting: In scenarios involving proxies or caching layers, injected CRLFs can lead to HTTP response splitting, allowing an attacker to deliver crafted responses to unsuspecting clients.
- Cache Poisoning: By inserting deceptive headers, attackers might manipulate shared caches to serve incorrect content to users.
- Session Fixation & Security Bypass: Injected session cookies or authentication bypass headers could alter the security context of a session, leading to elevated privileges or unauthorized access paths.
While such misuse requires control over header input — typically from a script or client interacting with the Gakido library — the risk is real in environments where user input influences outgoing HTTP requests (e.g., API clients, automated scanners, or intermediary services).
Proof of Concept
The advisory included a minimal proof of concept demonstrating how the infection might be triggered:
from gakido import Client
# Before fix: X-Injected header would be sent as a separate header
c = Client(impersonate="chrome_120")
r = c.get("https://httpbin.org/headers", headers={
"User-Agent": "test\r\nX-Injected: pwned"
})
In this example, the crafted User-Agent header contains a CRLF followed by another header (X-Injected: pwned). Without proper sanitization, Gakido sends the injected header to the server, effectively appending a malicious header to the request.
Mitigation and Fix
The developers of Gakido fixed the flaw upstream in commit 369c67e and released a patched version v0.1.1-1bc6019. Users of affected versions are strongly advised to upgrade to this fixed release as soon as possible.
Upgrading ensures that control characters in header names or values are correctly handled or rejected, preventing malformed headers from ever being constructed.
Timeline
- January 25, 2026 – Vulnerability was reported to maintainers.
- January 27, 2026 – The advisory was published and the fix released.
The advisory and related issue details are attributed to security researcher Omar Kurt, the author of the publishing site.
Conclusion
CRLF injection remains a class of vulnerabilities with serious implications for HTTP request integrity. In the case of Gakido, the issue stemmed from missing sanitization in the header normalization logic. Although the severity is marked as medium, the real-world impact could be significant in environments where HTTP headers are constructed from untrusted input.
Mitigation is straightforward: update to the fixed Gakido release and avoid allowing unvalidated input to influence header construction. In broader practice, developers should always treat HTTP header content with the same scrutiny as body or query parameters, particularly when third-party systems might interpret those headers downstream.
