Which versions of hackney are affected by CVE-2026-47067?

Erlang HTTP client hackney versions 2.0.0-4.0.0 contain a denial-of-service vulnerability that allows remote attackers to crash affected applications by sending specially crafted URLs, impacting any…. A patch is available.

Is there a public PoC exploit available for CVE-2026-47067?

Yes, a public proof-of-concept exploit is available for CVE-2026-47067. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate CVE-2026-47067?

Within 24 hours: identify all applications and deployments using hackney and document their current versions. Within 7 days: upgrade all affected services to hackney 4.0.1 or later. Within 30 days: validate patches in production and confirm successful deployment across all vulnerable systems.

hackney CVE-2026-47067

Q: What is the CVSS score of CVE-2026-47067?

CVE-2026-47067 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-31691 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-05-25 EEF

GHSA-9653-rcfr-5c62

Denial Of Service Hackney

8.7

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 09:38 vuln.today

Analysis Generated

Jun 08, 2026 - 09:38 vuln.today

CVSS changed

May 26, 2026 - 17:22 NVD

8.7 (HIGH)

CVE Published

May 25, 2026 - 14:00 nvd

UNKNOWN (no severity yet)

DescriptionCVE.org

Allocation of Resources Without Limits or Throttling vulnerability in benoitc hackney allows Flooding. The URL parser in src/hackney_url.erl converts every unrecognized URL scheme to a permanent BEAM atom via binary_to_atom/2. BEAM atoms are never garbage-collected and the atom table defaults to a hard limit of 1,048,576 entries. An attacker who can supply URLs with attacker-chosen scheme prefixes - directly as request targets, as configured webhook URLs, or via Location headers followed during redirects - can exhaust the atom table and crash the entire BEAM VM with system_limit.

This issue affects hackney: from 2.0.0 before 4.0.1.

AnalysisAI

Denial of service in benoitc hackney (Erlang HTTP client) 2.0.0 through 4.0.0 allows remote unauthenticated attackers to crash the BEAM VM by supplying URLs with attacker-chosen scheme prefixes, exhausting the non-garbage-collected atom table (default limit 1,048,576). Exploitation is automatable per SSVC and affects any application that parses untrusted URLs via hackney - including request targets, configured webhook URLs, or Location redirect headers. No public exploit identified at time of analysis and EPSS is low (0.04%), but a vendor patch is available in 4.0.1.

Technical ContextAI

hackney is a widely-used HTTP client library for Erlang/Elixir applications. The root cause (CWE-770: Allocation of Resources Without Limits or Throttling) lives in src/hackney_url.erl, where parse_url/1 invoked binary_to_atom/2 on the lowercased URL scheme. In the BEAM (Erlang virtual machine), atoms are interned into a global, never-garbage-collected table whose default ceiling is 1,048,576 entries; once exhausted, the VM aborts with a system_limit error and the entire Erlang node terminates. Because hackney_url is reachable any time the library parses a URL - including indirectly via Location headers during automatic redirect following - attacker-controlled scheme strings are converted into permanent atoms one per unique scheme observed. The upstream fix swaps binary_to_atom for binary_to_existing_atom with a binary fallback, so unknown schemes never mint new atoms and are simply rejected as unsupported_scheme downstream.

RemediationAI

Vendor-released patch: upgrade hackney to 4.0.1 or later, which replaces binary_to_atom with binary_to_existing_atom in hackney_url:parse_url so unknown schemes remain as binaries (commit 31f6f0e27e096ad88743dfded4f030a3ee74972e). See the advisory at https://github.com/benoitc/hackney/security/advisories/GHSA-9653-rcfr-5c62 for guidance. Where immediate upgrade is not possible, compensating controls include disabling automatic redirect following in hackney requests (trade-off: callers must handle 3xx responses manually), validating and allow-listing URL schemes (e.g. only http/https) before passing user-supplied URLs or webhook targets to hackney (trade-off: rejects legitimate uncommon schemes), and increasing the BEAM atom table limit via the +t emulator flag to delay exhaustion (trade-off: only buys time, does not prevent the underlying leak and increases memory ceiling). Auditing all code paths that feed externally influenced URLs into hackney is also recommended.