---
id: "CVE-2026-112880"
kind: "vulnerability"
aliases: ["CVE-2026-112880"]
title: "hackney: unchecked proxy auth value lets CRLF split requests to proxy"
severity: "low"
cvss: 2.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["elixir", "erlang", "hackney", "http-client", "package"]
not_affected_if: ["hackney-4.9.0-or-later", "no-proxy", "static-proxy-credentials"]
published_at: "2026-10-26T14:16:28+00:00"
first_seen_at: "2026-10-26T14:30:36+00:00"
updated_at: "2026-10-26T14:32:53+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112880", "first_seen_at": "2026-10-26T14:30:36+00:00"}]
---

# hackney: unchecked proxy auth value lets CRLF split requests to proxy

Erlang's hackney HTTP client writes whatever a proxy_auth_fun callback returns into a Proxy-Authorization header without stripping CR, LF or NUL bytes. If that value comes from untrusted data such as a proxy's challenge headers, an attacker can inject extra header lines into the CONNECT retry request sent to the proxy.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `rebar3 deps` or check `rebar.lock` for `hackney` at a version from `2.0.0` up to but not including `4.9.0`
- Search your code for `proxy_auth_fun` and check whether its return value is built from data a remote party can influence

## Fix

- Upgrade hackney to `4.9.0` or later
- Until upgraded, make sure `proxy_auth_fun` returns only values built from trusted credentials and never from proxy response headers

## Timeline

- 2026-10-26T14:30:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-112880

## From the sources

Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in hackney_http_connect in benoitc hackney allows HTTP Request Splitting via the value a proxy_auth_fun callback returns. After a 407 response from an HTTP CONNECT proxy, hackney_http_connect:handle_proxy_auth/11 calls the caller's proxy_auth_fun 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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_