Erlang OTP EUVD-2026-101390

Exploitation requires that the application extract an attacker-supplied tar archive to DISK via erl_tar:extract/1,2 (or the vendored hex_erl_tar/mix_hex_erl_tar/r3_hex_erl_tar equivalents), and that the archive contain a crafted GNU sparse member whose sparse map ends before its declared real size. Key limiting factors: extraction using the 'memory' output option is NOT affected; the {max_size, N} option only prevents the hang when N is set below the real size of the member. For stdlib's erl_tar the flaw applies only to OTP 29.0 before 29.1.2, but the vendored copies in hex_core (>=0.14.0), Hex (>=2.4.2), and rebar3 (>=3.27.1) are affected on ANY OTP version, including OTP 28. No attacker privileges or user interaction with the process are required beyond getting the archive into an extraction routine.

This is a genuine but moderate-priority availability-only issue (CWE-835 infinite loop), not a high-severity emergency. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N) scores 5.9 with impact limited to availability (VA:H; VC:N/VI:N), which is consistent with the description: a crafted 2048-byte GNU sparse tar member pins the extracting process and one scheduler at 100% until killed, with no code execution or data exposure. The AV:L (local) and AT:P (a specific attack precondition - the malformed sparse map) signals correctly convey that this is not a trivially remote, wormable flaw: the attacker must get a crafted archive into an extraction path. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - exploitation probability must be treated as unquantified rather than low. The practical risk is elevated by the distribution model: hex_core, Hex, and rebar3 ship their own vendored copies of erl_tar (hex_erl_tar/mix_hex_erl_tar/r3_hex_erl_tar) that are vulnerable on ANY OTP version (including OTP 28, which is otherwise unaffected), so build-time package extraction is a realistic trigger. One caveat to verify: although the vendor labels AV:L, package managers like Hex/rebar3 fetch and extract archives from remote repositories, so a supply-chain delivery path (malicious or compromised package) could effectively deliver the archive over a network even though the tar parsing itself is local - treat the AV:L as describing the parsing boundary, not the full delivery chain.

An attacker publishes or substitutes a malicious ~2 KB tar archive containing a GNU sparse member whose sparse map ends before the member's declared real size, then gets a victim to extract it (e.g., a CI/build host running rebar3 or Hex fetching the package, or an application calling erl_tar:extract to disk). When the member is streamed to disk, do_sparse_read matches the trailing-hole clause, reads zero bytes without advancing, and recurses forever, pinning the extracting process and one scheduler at 100% CPU until the process is killed. No public exploit code is identified, but the malformed-archive trigger is simple to construct from the detailed advisory.