CVE-2026-47075 — hackney
Fix: benoitc/hackney@ca73dd0CVE-2026-47075 is a CWE-93 vulnerability in hackney. A fix is available for hackney — see the affected versions and patch details below.
CR/LF injection in query parameter in hackney
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-2026-47075.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
hackneyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
hackney_url:make_url/3 passes the URL query component directly into the HTTP/1.1 request target without percent-encoding \r or \n. RFC 3986 §3.4 requires characters outside the query grammar to be percent-encoded, but no validation or escaping occurs. An attacker who controls any portion of the URL passed to hackney can inject raw CRLF sequences into the request line, enabling HTTP header injection or full request splitting.
Details
hackney_url:make_url/3 in src/hackney_url.erl builds the request target by concatenating the path and query binaries. The query string is used as-is — no character-class check, no percent-encoding of \r or \n. When hackney serializes the request, the query value lands verbatim in the GET <path>?<query> HTTP/1.1\r\n request line. A query value containing \r\n terminates the request line early; subsequent bytes are parsed by the server (or any intermediary proxy) as additional header lines or a second request.
A concrete example: a URL with query ?q=x HTTP/1.1\r\nX-Injected: yes\r\nX: produces the following on the wire:
GET /?q=x HTTP/1.1
X-Injected: yes
X: HTTP/1.1
Host: ...
The server sees X-Injected: yes as a legitimate request header that the client never intended to send.
PoC
- Listen on a raw TCP port:
nc -lvnp 8080. - Issue:
:hackney.get("http://127.0.0.1:8080/?q=x HTTP/1.1\r\nX-Injected: yes\r\nX:"). - Observe the listener receives
X-Injected: yesas a standalone header line in the request.
Impact
HTTP header injection and request splitting against any server hackney connects to. Affects all released versions of hackney before 4.0.1. Exploitation requires an attacker-controlled URL (or URL component) to reach hackney without prior sanitization. Consequences include injecting arbitrary headers (Authorization, Host, X-Forwarded-For) and splitting requests through proxies. CVSS v4.0: 6.8 (MEDIUM).
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | hackney | all versions | 4.0.1mix deps.update hackney |
Affected Products
hackneybenoitcDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hackney, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update hackney to 4.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-47075 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.
Frequently Asked Questions
Is CVE-2026-47075 in your dependencies?
Find it across Hex, including transitive dependencies.