CVE-2026-47067: Benoitc Hackney DOS Vulnerability

CVE-2026-47067 Overview

CVE-2026-47067 is a resource exhaustion vulnerability in hackney, a widely used HTTP client library for Erlang maintained by benoitc. The URL parser in src/hackney_url.erl converts every unrecognized URL scheme to a permanent BEAM atom using binary_to_atom/2. BEAM atoms persist for the lifetime of the virtual machine and the atom table defaults to a hard limit of 1,048,576 entries. An attacker who controls URL scheme prefixes can exhaust this table and crash the entire BEAM VM with a system_limit error. The flaw affects hackney from version 2.0.0 up to but not including 4.0.1, and is tracked under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
A remote, unauthenticated attacker can crash the entire Erlang VM by supplying URLs with unique scheme prefixes, terminating all services running on the node.

Affected Products

benoitc hackney versions 2.0.0 through 4.0.0
Erlang/OTP applications using hackney as an HTTP client
Services that follow attacker-influenced redirects or webhook URLs via hackney

Discovery Timeline

2026-05-25 - CVE-2026-47067 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-47067

Vulnerability Analysis

The vulnerability lives in hackney's URL parsing logic in src/hackney_url.erl. When the parser encounters a URL scheme it does not recognize, it calls binary_to_atom/2 on the scheme string. The Erlang runtime treats atoms as immutable global identifiers and never garbage-collects them. Every unique scheme an attacker supplies adds a permanent entry to the BEAM atom table.

The default atom table limit is 1,048,576 entries. Once the limit is reached, the VM terminates with system_limit, taking down every Erlang process on the node. Because hackney is embedded in many production HTTP client paths, the parser may be reached through request targets, configured webhook destinations, or Location headers followed during redirects.

Root Cause

The root cause is the unsafe use of binary_to_atom/2 on untrusted input. The safer primitive binary_to_existing_atom/2 would have rejected unknown schemes instead of registering them. The fix in commit 31f6f0e27e096ad88743dfded4f030a3ee74972e (released in hackney 4.0.1) replaces dynamic atom creation with a bounded lookup against a known set of schemes.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker triggers atom-table growth in any of three ways. First, they submit URLs with random scheme prefixes such as aaaa1://target, aaaa2://target, and so on, when the application accepts user-supplied URLs. Second, they configure attacker-controlled webhook destinations with novel scheme strings. Third, they cause hackney to follow redirects whose Location headers carry unique schemes. Each unique scheme consumes one permanent atom slot until the VM crashes.

// No verified public exploit code is available.
// See the GitHub Security Advisory GHSA-9653-rcfr-5c62 for technical details.

Detection Methods for CVE-2026-47067

Indicators of Compromise

Sudden BEAM VM termination with system_limit reported in erl_crash.dump files
Steady growth in erlang:system_info(atom_count) over time, especially correlated with HTTP traffic
Inbound requests or webhook configurations containing non-standard URL schemes such as random alphanumeric prefixes
Outbound HTTP redirects from external endpoints returning Location headers with unusual scheme values

Detection Strategies

Instrument applications using hackney to log and alert when erlang:system_info(atom_count) exceeds a baseline threshold
Inspect HTTP access logs and webhook configuration tables for URL schemes outside the expected set such as http, https, ws, and wss
Monitor process supervisors and orchestrators for repeated BEAM crashes accompanied by system_limit errors

Monitoring Recommendations

Emit telemetry for atom-table utilization and trigger alerts at 50%, 75%, and 90% of the configured +t limit
Centralize Erlang crash dumps and parse them for system_limit reasons to correlate with vulnerable hackney versions
Track the version of hackney deployed across services via software bill of materials tooling and flag any release below 4.0.1

How to Mitigate CVE-2026-47067

Immediate Actions Required

Upgrade hackney to version 4.0.1 or later across all Erlang and Elixir services
Audit dependency trees for transitive use of hackney via libraries such as HTTPoison and rebuild any affected releases
Restrict user-supplied and webhook URL schemes to an allowlist of http and https at the application layer
Inspect existing webhook and integration configurations for previously stored URLs with unusual schemes and remove them

Patch Information

The fix is available in hackney 4.0.1. Review the upstream commit at GitHub Commit 31f6f0e and the advisory at GHSA-9653-rcfr-5c62. Additional references are available in the Erlang Ecosystem Foundation CNA advisory and the OSV record EEF-CVE-2026-47067.

Workarounds

Validate URL schemes against an allowlist before passing them to any hackney API call
Reject or normalize Location headers with unknown schemes when handling redirects in calling code
Disable automatic redirect following in hackney for endpoints that contact untrusted hosts
Increase BEAM atom table monitoring and configure orchestrators to restart nodes before exhaustion if patching is not immediately feasible

bash

# Update hackney in a rebar3 project
rebar3 upgrade hackney

# Or pin the minimum safe version in rebar.config
# {deps, [{hackney, "~> 4.0.1"}]}.

# For mix-based Elixir projects, in mix.exs:
# {:hackney, "~> 4.0.1"}
mix deps.update hackney