Description
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.
Published: 2026-10-12
Score: 2.1 Low
EPSS: < 1% Very Low
KEV: No
Impact: Resource Exhaustion
Action: Upgrade
AI Analysis

Impact

A malicious or compromised package mirror can serve extremely large or highly compressed files that are processed by Hex without size limits. The untrusted mirror is fully trusted for download, so Hex downloads the entire response, decompresses gzip-encoded data, and buffers payloads such as package tarballs, docs archives, or registry responses fully in memory or on disk before verifying checksums. The lack of a limit on compressed or decompressed size allows the mirror to exhaust the machine's RAM or disk space, causing Mix commands that rely on Hex to fail or terminate. This vulnerability represents a denial of service due to resource exhaustion (CWE-409: Excessive Resource Consumption and CWE-770: Allocation of Resources Without Limits).

Affected Systems

All installations of Hex versions from 0.11.2 up to, but not including, 2.5.2 are affected. The issue was addressed in Hex 2.5.2 and later releases, which impose a maximum of 16 MiB on the uncompressed size of download artifacts and validate registry signatures before caching or unpacking packages. Users of earlier releases must identify the specific patch level by consulting the version history of the Hex package.

Risk and Exploitability

The CVSS score of 2.1 indicates a low severity, and the EPSS score is not available, suggesting no publicly known exploits and a low likelihood of exploitation. Because the attack requires control over a package mirror, an adversary must either compromise an existing mirror or set up a malicious mirror on the network. The vulnerability is local to the system running Mix; it does not allow remote code execution or compromise of the host beyond exhausting resources. The risk is therefore limited to a local denial of service that could affect development or continuous‑integration environments, especially when Mix is executed in resource‑constrained containers.

Generated by OpenCVE AI on October 12, 2026 at 16:25 UTC.

Remediation

Vendor Solution

Upgrade Hex to 2.5.2 or later, for example with mix local.hex. Hex then stops downloading a registry file, package, docs tarball or other file from a repository or mirror once it's larger than 16 MiB, including after decompressing a gzip-encoded response, and checks packages against the registry checksum before writing them to the package cache or unpacking a cached copy.

Vendor Workaround

Fetch from repo.hex.pm or a mirror you operate. Running Mix under operating system memory and disk limits, such as container limits, confines the effect to that container.

OpenCVE Recommended Actions

  • Upgrade Hex to 2.5.2 or later to enforce size limits and checksum validation
  • Use a trusted source such as repo.hex.pm or operate your own mirror to avoid untrusted downloads
  • Run Mix inside an environment that imposes memory and disk limits, for example by using Docker or other container isolation

Generated by OpenCVE AI on October 12, 2026 at 16:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 20 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

 cvssV3_1

{'score': 4.3, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L'}

threat_severity

Moderate

Sat, 17 Oct 2026 13:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Mon, 12 Oct 2026 15:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Hex exhausts memory and disk on oversized or compressed responses from an untrusted mirror
First Time appeared Hexpm
Hexpm hex
Weaknesses CWE-409
CWE-770
CPEs cpe:2.3:a:hexpm:hex:*:*:*:*:*:*:*:*
Vendors & Products Hexpm
Hexpm hex
References
Metrics cvssV4_0

{'score': 2.1, 'vector': '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'}

Subscriptions

Hexpm Hex
cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-10-16T17:33:51.114Z

Reserved: 2026-10-10T13:00:02.352Z

Link: CVE-2026-96618

cve-icon Vulnrichment

Updated: 2026-10-16T17:33:46.579Z

cve-icon NVD

Status : Deferred

Published: 2026-10-12T16:17:07.920

Modified: 2026-10-16T18:19:52.930

Link: CVE-2026-96618

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-12T15:29:19Z

Links: CVE-2026-96618 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-12T17:00:13Z

Weaknesses
  • CWE-409

    Improper Handling of Highly Compressed Data (Data Amplification)

  • CWE-770

    Allocation of Resources Without Limits or Throttling