hackney EUVD-2026-109837

The victim application must use hackney to issue a request whose full body is buffered - the default hackney:request/5 result or hackney:body/1 - to a server the attacker controls or can influence the response of (reachable directly, via redirect, or via a client-supplied/SSRF URL). The oversized-body path requires no special configuration: before 4.9.0 the HTTP/1.1, HTTP/2 and HTTP/3 accumulators had no size limit, so default deployments are affected. The compression-amplification path additionally requires the {auto_decompress, true} option, under which the entire body is inflated in a single zlib:gunzip/1 or zlib:inflate/2 call. Limiting factors: exploitation yields only availability loss (no data exposure), the client must actually initiate the connection to the hostile server, and installing 4.9.0 (or setting max_body_size) caps buffering and returns {error, body_too_large}.

This is a client-side memory-exhaustion (CWE-409 data-amplification) denial-of-service in the hackney HTTP client, and the available signals point to a moderate-but-real priority rather than an emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) and the availability-only impact (VC:N/VI:N/VA:H) are internally consistent with the description: no authentication, network-reachable, no confidentiality or integrity loss, and an attack requirement (AT:P) reflecting that the victim client must actually issue a request to a server that then returns the hostile body. The vuln.today decision label is 'this_week' and a vendor patch (4.9.0) is confirmed available, which aligns with a serious-but-non-critical DoS. No EPSS score, no CISA KEV listing, and no proof-of-concept exploit reference are present in the input - so there is no public exploit identified at time of analysis, and the realistic threat is a malicious or compromised server (or one reachable via SSRF/redirect) degrading or crashing the client's Erlang VM, not mass remote compromise. The one data-quality conflict to flag explicitly: the input Tags label this 'Information Disclosure', which contradicts the CVSS vector (VC:N, VA:H) and the description - this is an availability/DoS issue, not disclosure, so treat the tag as mislabeled.

An application using hackney makes an HTTP request (directly, or via a redirect / user-supplied URL) to a server the attacker controls or has compromised. That server replies with an endless or highly gzip-compressed body; hackney buffers the entire response via hackney_conn:read_full_body/2 (or the HTTP/2 / HTTP/3 accumulators) with no size cap, and with {auto_decompress, true} inflates the whole payload in one zlib call, exhausting the client process's memory. No public exploit code is referenced in the input, but the trigger is trivial for any server that answers the client's request.