hex_core EUVD-2026-97568

Requires the attacker to control the data served to the hex_core/Hex/rebar3 client: an untrusted or compromised repository mirror, a malicious server answering hex_core's API requests, or a network MITM on the fetch. Two code paths are vulnerable: hex_repo:get_names/1, get_versions/1, get_package/2 and get_policy/2 run zlib:gunzip/1 and decode the signed envelope BEFORE verifying the signature (so no repository private key is needed - the mirror only controls the compressed bytes); and hex_api decoding of application/vnd.hex+erlang responses via hex_safe_binary_to_term:safe_binary_to_term/1 calls binary_to_term(Binary, [safe]), which still accepts compressed terms and does not bound decoded size, with the function/port rejection running only after the term is built. Limiting factors: the victim must actively run a Hex/mix/rebar3 fetch operation (UI:A), the attacker must be positioned as the mirror/API server or MITM (AT:P), and it is not exploitable against the default trusted hex.pm repository over TLS unless that server or transport is compromised; impact is confined to memory exhaustion of the client-side Erlang VM (no code execution, no data exposure).

This is a low-severity availability issue, not a high-priority emergency. The CNA-supplied CVSS 4.0 vector (base 2.1) captures it well: AV:N but AT:P and UI:A, with impact limited to VA:L and no confidentiality or integrity effect (VC:N/VI:N). The flaw is a decompression/data-amplification bomb (CWE-409): because hex_repo decompresses via zlib:gunzip/1 and hex_api decodes compressed Erlang terms via binary_to_term before the signature/safety checks complete, a small crafted response can balloon into an arbitrarily large term and exhaust the Erlang VM's memory. Crucially, exploitation is NOT remote-unauthenticated-against-anyone: the attacker must be the repository mirror or API server the client talks to (or a network MITM), and the client must actively initiate a fetch (AT:P + UI:A), so this is positional rather than broadly sprayable. No EPSS score was provided (unknown), the CVE is NOT in CISA KEV, and no public exploit was identified in the supplied data, so there is no evidence of active exploitation. The one tension to flag: the input Tags label this 'Information Disclosure', which directly contradicts the CWE-409 category and the availability-only impact metrics - this is a denial-of-service/resource-exhaustion bug, not disclosure. Priority: patch during normal maintenance, prioritizing environments that fetch from untrusted or self-hosted mirrors.

A developer or CI pipeline configures Hex/rebar3 to use an untrusted or compromised repository mirror (or an attacker MITMs the fetch). When the client calls get_names/get_versions/get_package or a hex+erlang API endpoint, the attacker returns a few kilobytes of highly compressed data that decompresses into a multi-gigabyte envelope/term before the signature or safety check runs, exhausting the Erlang VM memory and crashing the build/fetch process. No public exploit code was identified in the provided intelligence.