Skip to main content

Hex EUVDEUVD-2026-97500

| CVE-2026-96618 LOW
Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)
2026-10-12 EEF
2.1
CVSS 4.0 · Vendor: EEF
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Attacker controls victim's configured Hex mirror
  2. Delivery
    Victim runs mix deps.get or hex.docs fetch
  3. Exploit
    Mirror returns gzip bomb or oversized tarball
  4. Execution
    Hex decompresses with no size cap before checks
  5. Impact
    Host memory or disk exhausted (DoS)

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V2 - Validation and Business Logic Compression ratio limits
Exploitation Conditions

Exploitation requires that the victim has a non-default, attacker-controlled Hex mirror configured via HEX_MIRROR_URL, HEX_MIRROR, or the mirror_url option, AND actively runs one of mix deps.get, mix deps.update, mix hex.package fetch, mix hex.docs fetch (or mix hex.docs offline when docs are missing). The vulnerable paths - Hex.HTTP.request/5 gzip decompression via :zlib.gunzip/1, unbounded package tarball download/unpack, and docs tarball extraction via :mix_hex_erl_tar.extract/2 - all consume memory or disk in proportion to attacker-supplied data before signature and 16 MiB/128 MiB size checks run. Limiting factors that reduce real-world risk: the default hex.pm CDN is not affected (only a configured untrusted mirror is), explicit user action is required to trigger a fetch, docs tarballs are not covered by the registry signature at all, and impact is limited to resource exhaustion (no code execution or data disclosure).

Impact

This is a genuinely low-priority issue despite being a real, vendor-confirmed vulnerability. The CVSS 4.0 base score of 2.1 (vendor/erlef CNA) is consistent with the vector: impact is confined to availability (VC:N/VI:N/VA:L) - a denial-of-service via memory/disk exhaustion, with no confidentiality or integrity consequence. Crucially, exploitation carries an attack requirement (AT:P) and active user interaction (UI:A): the victim must already have an attacker-controlled Hex mirror configured (HEX_MIRROR_URL/HEX_MIRROR/mirror_url) and must run a fetch command (mix deps.get, deps.update, hex.package fetch, or hex.docs fetch). This is a significant limiting factor - the default configuration uses hex.pm's own CDN, not an untrusted mirror, so most deployments are not exposed. No EPSS score was provided in the input, there is no CISA KEV listing, and no public exploit was supplied, so there is no signal of real-world exploitation. The AV:N vector is accurate in that the malicious payload arrives over the network, but it should not be read as 'remotely exploitable against any default install' - the network attacker must occupy the position of the configured mirror. Net assessment: a legitimate supply-chain hardening fix worth patching in CI/build environments that use third-party mirrors, but not an urgent, widely-exploitable threat.

Exploit ScenarioDerived

A development team or CI pipeline configures a third-party or internal Hex mirror via HEX_MIRROR_URL and runs mix deps.get or mix hex.docs fetch. The malicious (or compromised) mirror returns a gzip-compressed decompression bomb, or an oversized package/docs tarball, which Hex reads fully into memory and decompresses with no size limit before any registry-signature or checksum validation runs, exhausting the host's memory or disk and crashing the build. No public exploit was identified at time of analysis.

Monitor Track and reassess. Why: LOW severity (CVSS 0.1-3.9).
Patch available 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 12, 2026

Resource exhaustion in the Hex package manager for Elixir (0.11.2 up to, but not including, 2.5.2) lets an untrusted, attacker-controlled package mirror consume unbounded memory or disk on the machine running mix deps.get, mix deps.update, mix hex.package fetch, or mix hex.docs fetch. Hex decompresses gzip response bodies and downloads/extracts package and docs tarballs before any signature, checksum, or 16 MiB/128 MiB size limits are applied, so the mirror's own payload size dictates consumption. Exploitation is narrow: it requires a non-default attacker-controlled mirror configured via HEX_MIRROR_URL, HEX_MIRROR, or the mirror_url option plus explicit user action to run a fetch, the default hex.pm CDN is not affected, and no public exploit has been identified at time of analysis (unauthenticated per CVSS PR:N, but user interaction is required and impact is availability-only, assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:R/C:N/I:N/A:L).

RemediationAI

Vendor-released patch: upgrade Hex to 2.5.2 or later (run mix local.hex --force or update the Elixir toolchain release that bundles Hex), which enforces size limits on responses and tarballs before they are decompressed, buffered, or extracted. The fixes land in commits https://github.com/hexpm/hex/commit/bb5189eade682c5fc3f98d9725973a7beb4e1deb and https://github.com/hexpm/hex/commit/08956100a8283ba500a123e5539ac64d5d7e91d8, with related changes in https://github.com/hexpm/hex/commit/51ea632424fb6ea8765148f96dc25dfeb526b1f8; see the advisory at https://github.com/hexpm/hex/security/advisories/GHSA-gf42-pg2f-63jp. If upgrading immediately is not possible, the most effective compensating control is to remove any custom mirror configuration - unset HEX_MIRROR_URL and HEX_MIRROR and drop mirror_url from .hex/config - so Hex uses the default hex.pm CDN, which this issue does not affect; the trade-off is loss of any private/air-gapped mirror, and note that docs tarballs are not registry-signed, so a mirror can supply arbitrary docs content regardless. Additionally, run mix deps.get/deps.update/hex.package fetch/hex.docs fetch inside a container or CI job with cgroup memory and disk quotas so an amplification payload degrades or kills the sandboxed job rather than the host - this contains but does not prevent the fetch and requires build-infrastructure changes. Restrict network egress so only vetted mirror hosts are reachable from build agents (blocks a DNS- or config-redirected mirror), and note that the registry-response decompression path resides in vendored hex_core code covered by GHSA-7c4r-cgf9-9jmq, so verify whether a corresponding hex_core/Hex update is required for full coverage of that path. There is no Hex configuration option that disables gzip response decompression ahead of the 2.5.2 fix.

Affected VersionsENISA

hex 0.11.2 <2.5.2
hex 51ea632424fb6ea8765148f96dc25dfeb526b1f8 <*

Affected Packages

euvd hex fix: 2.5.2

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The root cause is CWE-409 (Improper Handling of Highly Compressed Data / data amplification), the class that covers decompression and archive-expansion bombs. Three distinct code paths in Hex consume resources proportional to attacker-supplied input before any validation: (1) Hex.HTTP.request/5 reads the entire response body into memory and decompresses it with :zlib.gunzip/1 whenever a response's Content-Encoding header contains gzip, with no cap on either the compressed or the decompressed size - Hex never requests compressed responses, so a malicious mirror decides whether that step runs, and the path applies to registry, package, docs, and API responses; (2) package tarball downloads have no size limit, with Hex 2.5.1 buffering the whole tarball in memory before writing it to the cache (the development branch streams to a temporary file instead), and the 16 MiB tarball limit only being enforced at unpack time, after which the tarball is extracted into deps/<app> (2.5.1) or a staging directory (dev branch) before checksums are compared against the signed registry; (3) mix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 normally applies - and because the signed registry does not cover docs tarballs, nothing authenticates them at any point. Hex deliberately treats a configured mirror as untrusted: it withholds credentials and verifies registry signatures and package checksums the mirror cannot forge, but in every case above the memory/disk consumption happens before those checks execute, so the trust model does not prevent the resource exhaustion. The registry-response decompression-before-signature-verification issue lives in vendored hex_core code and is tracked separately at https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.

Know when Hexpm gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (EEF) PRIMARY 2.1 LOW
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
vuln.today AI 3.1 LOW

Payload arrives over the network (AV:N) but requires an attacker-controlled configured mirror (AC:H) and the victim running a fetch command (UI:R); impact is resource-exhaustion availability only (A:L).

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L
4.0 AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (EEF).

CVSS VectorVendor: EEF

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
Active
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
None
Vulnerable system: Availability
Low
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex allows an untrusted package mirror to exhaust the memory or disk space of the machine running mix deps.get, mix deps.update, mix hex.package fetch or mix hex.docs fetch.

Hex treats a mirror configured with HEX_MIRROR_URL, HEX_MIRROR or mirror_url as untrusted: it doesn't send credentials to it, and it checks registry signatures and package checksums that the mirror can't forge. Several response paths consume memory or disk in proportion to what the mirror sends before any of those checks run.

Hex.HTTP.request/5 reads the whole response body into memory and decompresses it with :zlib.gunzip/1 whenever the response's Content-Encoding contains gzip, with no limit on the compressed or decompressed size. Hex doesn't ask for compressed responses, so the server decides whether this step runs. It applies to registry, package, docs and API responses.

Package tarballs have no download size limit. Hex 2.5.1 holds the whole tarball in memory and writes it to the cache, and the development branch streams it to a temporary file; the 16 MiB tarball limit is checked only when the file is unpacked. The tarball is then unpacked, into deps/<app> in 2.5.1 and into a staging directory on the development branch, before its checksums are compared with the registry.

mix hex.docs fetch, and mix hex.docs offline when docs are missing, write the docs tarball to disk and extract it with :mix_hex_erl_tar.extract/2 without the 16 MiB compressed and 128 MiB decompressed limits that mix_hex_tarball:unpack_docs/3 applies. The signed registry doesn't cover docs tarballs, so nothing checks them.

Registry responses are also decompressed before their signature is checked, in hex_core code that Hex vendors; that part is tracked in https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq.

This issue affects hex: from 0.11.2 before 2.5.2.

Threat Intelligence Overview

EPSS Score
0.3%
Top 76% exploitable
Prevalence
Medium
default package manager for Elixir/Erlang, a moderately-adopted ecosystem
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity LOW
CISA KEV No
Public POC No
EPSS 0.3%
Patch available Yes
Active threat No
Deciding rule
LOW severity (CVSS 0.1-3.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact· derived
Low

Priority Score

10
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +10
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

More in Hexpm

View all
CVE-2026-21622 CRITICAL
9.5 Mar 05

Insufficient session expiration in hexpm. Password reset tokens never expire, enabling persistent account takeover.

CVE-2026-32148 HIGH
8.9 Apr 30

Silent dependency checksum bypass in hexpm/hex package manager (versions 0.16.0 through 2.4.1) allows attackers to subst

CVE-2026-21618 HIGH
8.5 Jan 19

Improper input sanitization in hexpm's SharedAuthorizationView module allows unauthenticated attackers to inject malicio

CVE-2026-75542 HIGH
8.3 Aug 24

Incorrect authorization in the hex.pm OAuth `client_credentials` endpoint allows any API key bearing the `repositories`

CVE-2026-96612 HIGH
7.5 Oct 12

Path traversal in the Hex package manager for the Elixir/Erlang (Mix) ecosystem, versions 0.6.0 through 2.5.1, lets a ma

CVE-2026-105668 HIGH
7.1 Oct 12

Hex, the package manager used by Elixir and Erlang projects, fails to properly scope its 'release-age cooldown' protecti

CVE-2026-23940 HIGH
7.1 Mar 13

An uncontrolled resource consumption vulnerability in the Hex.pm package manager allows authenticated attackers to cause

CVE-2026-21621 HIGH
7.0 Mar 05

Hexpm's OAuth implementation fails to enforce read-only API key restrictions during token exchange, allowing an attacker

CVE-2026-105280 MEDIUM
6.9 Oct 12

Integrity-check bypass in the Hex package manager (hexpm hex) allows a compromised or attacker-controlled package mirror

CVE-2026-23939 MEDIUM
6.9 Feb 26

Path traversal in hexpm's Local Storage backend allows unauthenticated attackers to read sensitive files through relativ

CVE-2026-103502 MEDIUM
5.9 Oct 12

Improper TLS server-certificate validation in hex_core (0.1.0 through versions before 0.20.0) lets an attacker who alrea

CVE-2026-103503 MEDIUM
5.9 Oct 12

Improper certificate validation in Hex (the Elixir/Erlang package manager client, versions 0.20.2 through 2.5.1) allows

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy