CVE-2026-96618— Hex内存与磁盘耗尽漏洞（过大或压缩响应）
一分钟漏洞结论
影响对象
hexpm hex
利用判断
尚无明确在野利用证据，仍需结合暴露面评估
建议动作
优先检查厂商安全公告和参考链接中的修复版本；无法立即升级时，限制受影响服务暴露并加强监测。
以下是该漏洞描述信息的中文翻译： 高压缩数据处理不当（数据放大）漏洞 存在于 hexpm hex 中。该漏洞允许不受信任的软件包镜像耗尽运行 、 、 或 的机器的内存或磁盘空间。 Hex 将配置了 、 或 的镜像视为不受信任：它不会向其发送凭据，并且会检查注册表签名和软件包校验和，以防止镜像伪造这些签名。然而，在运行任何这些检查之前，有几个响应路径会根据镜像发送的数据量成比例地消耗内存或磁盘空间。 函数会将整个响应正文读取到内存中，并在响应的 包含 时通过 对其进行解压缩，且不对压缩前或解压缩后的大小设置任何限制。
获取后续新漏洞提醒
登录后订阅
一、 漏洞 CVE-2026-96618 基础信息
漏洞信息
对漏洞内容有疑问？看看神龙的深度分析是否有帮助！
查看神龙十问 ↗
尽管我们使用了先进的大模型技术，但其输出仍可能包含不准确或过时的信息。神龙努力确保数据的准确性，但请您根据实际情况进行核实和判断。
Vulnerability Title
Hex exhausts memory and disk on oversized or compressed responses from an untrusted mirror
来源: CVE Program / CVE List V5
Vulnerability 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.
来源: CVE Program / CVE List V5
CVSS Information
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
来源: CVE Program / CVE List V5
Vulnerability Type
对高度压缩数据的处理不恰当(数据放大攻击)
来源: CVE Program / CVE List V5
受影响产品
二、漏洞 CVE-2026-96618 的公开POC
| # | POC 描述 | 源链接 | 神龙链接 |
|---|
AI 生成 POC
高级
未找到公开 POC。
登录以生成 AI POC三、漏洞 CVE-2026-96618 的情报信息
请登录查看更多情报信息。
CVE-2026-96618 其他参考 (6)
同批安全公告 · hexpm · 2026-10-12 · 共 7 条
| CVE-2026-96612 | 7.5 HIGH | Hex 通过未验证的依赖应用名实现路径遍历漏洞 |
| CVE-2026-105668 | 7.1 HIGH | Hex 发布年龄冷却包级提升漏洞 |
| CVE-2026-105280 | 6.9 MEDIUM | Hex mix hex.package fetch 未验证包输出漏洞 |
| CVE-2026-103502 | 5.9 MEDIUM | hex_core默认HTTP适配器未验证TLS证书（OTP 24/25） |
| CVE-2026-103503 | 5.9 MEDIUM | Hex cacerts_path 配置信任捆绑CA证书漏洞 |
| CVE-2026-81856 | 2.3 LOW | Hex 终端转义序列注入漏洞 |
IV. Related Vulnerabilities
V. Comments for CVE-2026-96618
暂无评论