CVE-2026-112880: CRLF injection in Proxy-Authorization header built from proxy_auth_fun in hackney

Q: Who is exposed to this issue?

Applications using hackney versions from 2.0.0 before 4.9.0 are exposed only on the HTTP CONNECT proxy authentication path when they supply a proxy_auth_fun callback. The callback's returned value must be influenced by untrusted data, such as proxy challenge headers.

Q: What does an attacker need to exploit it?

An attacker needs to cause a 407 response from an HTTP CONNECT proxy and have the application's proxy_auth_fun return a value containing a CR, LF, or NUL byte. Those bytes are written into the Proxy-Authorization request line on the CONNECT retry and can add headers to the request sent to the proxy.

Q: Is the normal CONNECT request path otherwise protected from control-character injection?

The target host and request-header values supplied by callers on the CONNECT path were already checked for control bytes. The missing validation specifically applies to the value returned by proxy_auth_fun after a 407 response.

Q: What can be done if upgrading is not immediately possible?

Ensure proxy_auth_fun never returns values containing CR, LF, or NUL bytes, particularly when constructing the value from proxy challenge headers or other untrusted input. Upgrade hackney to 4.9.0 or later when possible.

Published Oct 26, 2026

Updated

Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackneyhttpconnect in benoitc hackney allows HTTP Request Splitting via the value a proxyauthfun callback returns. After a 407 response from an HTTP CONNECT proxy, hackneyhttpconnect:handleproxyauth/11 calls the caller's proxyauthfun with the status code and the response headers and writes the returned binary into the Proxy-Authorization line of the CONNECT retry without checking it. A CR, LF or NUL byte in that value adds header lines to the request sent to the proxy.

The value is attacker-influenced when the callback derives it from untrusted data, for example from the proxy's challenge headers. Other caller-supplied values on the CONNECT path, such as the target host and the request headers, were already checked for control bytes.

This issue affects hackney: from 2.0.0 before 4.9.0.

Affected Software

1 affected component

hex/hackney>=2.0.0<4.9.0

Event History

Oct 26, 2026

CVE Published

via MITRE·01:48 PM

Data Sourced

via MITRE·01:48 PM

DescriptionWeakness

Frequently Asked Questions

Who is exposed to this issue?

Applications using hackney versions from 2.0.0 before 4.9.0 are exposed only on the HTTP CONNECT proxy authentication path when they supply a proxy_auth_fun callback. The callback's returned value must be influenced by untrusted data, such as proxy challenge headers.

What does an attacker need to exploit it?

An attacker needs to cause a 407 response from an HTTP CONNECT proxy and have the application's proxy_auth_fun return a value containing a CR, LF, or NUL byte. Those bytes are written into the Proxy-Authorization request line on the CONNECT retry and can add headers to the request sent to the proxy.

Is the normal CONNECT request path otherwise protected from control-character injection?

The target host and request-header values supplied by callers on the CONNECT path were already checked for control bytes. The missing validation specifically applies to the value returned by proxy_auth_fun after a 407 response.

What can be done if upgrading is not immediately possible?

Ensure proxy_auth_fun never returns values containing CR, LF, or NUL bytes, particularly when constructing the value from proxy challenge headers or other untrusted input. Upgrade hackney to 4.9.0 or later when possible.

CVE-2026-112880: CRLF injection in Proxy-Authorization header built from proxy_auth_fun in hackney

Affected Software

Event History

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to exploit it?

Is the normal CONNECT request path otherwise protected from control-character injection?

What can be done if upgrading is not immediately possible?

Company

Resources

Contact

Frequently Asked Questions

Who is exposed to this issue?

What does an attacker need to exploit it?

Is the normal CONNECT request path otherwise protected from control-character injection?

What can be done if upgrading is not immediately possible?