CVE-2026-47075 benoitc CVE debrief

Who should care

Organizations running Erlang/Elixir applications using hackney versions prior to 4.0.1 for outbound HTTP requests, particularly those constructing URLs from untrusted user input. Development teams should prioritize patching and auditing URL construction patterns.

Technical summary

The hackney Erlang HTTP client library versions prior to 4.0.1 fail to properly neutralize CRLF sequences in URL query components. When constructing HTTP/1.1 request targets, hackney_url:make_url/3 passes the query binary directly without percent-encoding CR (0x0D) or LF (0x0A) characters as required by RFC 3986 Section 3.4. An attacker controlling URL query parameters can inject raw CRLF sequences that are transmitted as HTTP line breaks, enabling arbitrary header injection or request splitting. This vulnerability requires attacker control of URL components but can lead to cache poisoning, credential hijacking, or request routing manipulation in affected applications.

Defensive priority

medium

Recommended defensive actions

• Upgrade hackney to version 4.0.1 or later
• Audit application code for any locations where untrusted user input is incorporated into URL query parameters passed to hackney
• Implement input validation to reject or sanitize CR (0x0D) and LF (0x0A) characters in URL components before passing to HTTP client libraries
• Consider using HTTP/2 where available, as the binary framing protocol is not susceptible to this class of request splitting attacks
• Review outbound HTTP request logging for anomalous header injection patterns

Evidence notes

The vulnerability stems from hackney_url:make_url/3 passing query binary directly without validation or escaping. The fix commit ca73dd0aba0ed557449c18288bf07241671a43c9 addresses this issue. Affected versions span from 0 through 4.0.0; version 4.0.1 contains the remediation.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.