Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - Hexpm Hex 中的不當處理高度壓縮資料 （資料放大） 弱點允許不受信任的套件鏡像耗盡執行 mix deps.get、mix deps.update、mix hex.package fetch 或 mix hex.docs fetch 的電腦的記憶體或磁碟空間。Hex 會將設定有 HEX_MIRROR_URL、HEX_MIRROR 或 mirror_url 的鏡像視為不受信任：它不會傳送憑證給它，而且會檢查鏡像無法偽造的登錄簽章和套件總和檢查碼。數個回應路徑會耗用記憶體或磁碟，其耗用量與鏡像在執行任何這些檢查之前所傳送的內容成比例。Hex.HTTP.request/5 會將整個回應內文讀取到記憶體中，並在回應的內容編碼包含 gzip 時使用 ：zlib.gunzip/1 解壓縮，對壓縮或解壓縮的大小沒有限制。Hex 不會要求壓縮回應，因此伺服器會決定是否執行此步驟。它適用於登錄檔、套件、文件和 API 回應。套件 tarball 沒有下載大小限制。Hex 2.5.1 將整個 tarball 保存在記憶體中並將其寫入快取，而開發分支則將其串流至暫存檔案;只有在解壓縮檔案時才會檢查 16 MiB tarball 限制。然後將 tarball 解壓縮到 deps/<app> in 2.5.1 和 development 分支上的暫存目錄中，然後再將其總和檢查碼與登錄進行比較。 混合 hex.docs 擷取，並離線混合 hex.docs 當缺少文件時，將 docs tarball 寫入磁碟並使用 ：mix_hex_erl_tar.extract/2 將其解壓縮，而沒有 16 MiB 壓縮和 128 MiB 解壓縮限制，這mix_hex_tarball：適用 unpack_docs/3。簽名的登錄不涵蓋文檔 tarball，因此沒有任何檢查它們。登錄響應在檢查其簽名之前也會以 Hex 供應商hex_core代碼中解壓縮;該部分在 中 https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq追蹤。此問題影響 hex： from 0.11.2 before 2.5.2。（CVE-2026-96618）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - hexpm hex 中的高度压缩数据处理不当（数据放大）漏洞允许不受信任的程序包镜像耗尽运行 mix deps.get、mix deps.update、mix hex.package 获取或 mix hex.docs 获取的计算机的内存或磁盘空间。Hex 将以 HEX_MIRROR_URL、HEX_MIRROR 或 mirror_url 配置的镜像视为不受信任：它不向其发送凭据，它会检查镜像无法伪造的注册表签名和程序包校验和。多个响应路径消耗内存或磁盘的数量与镜像在运行任何这些检查之前发送的内容成正比。Hex.HTTP.request/5 会将整个响应正文读入内存，并在响应的内容编码中包含 gzip 时使用 ：zlib.gunzip/1 对其进行解压缩，对压缩或解压缩的大小没有限制。Hex 不要求压缩响应，因此服务器决定是否运行此步骤。它适用于注册表、程序包、文档和 API 响应。程序包 tarball 没有下载大小限制。Hex 2.5.1 将整个 tarball 保存在内存中并将其写入缓存，开发分支将其流式传输到临时文件;仅当解包文件时才检查 16 MiB tarball 限制。然后将 tarball 解压缩到 deps/<app> 中 2.5.1 ，然后放入开发分支上的暂存目录中，然后将其校验和与注册表进行比较。 混合 hex.docs 提取，并在缺少 docs 时离线混合 hex.docs，将 docs tarball 写入磁盘并使用 ：mix_hex_erl_tar.extract/2 提取，而没有 16 MiB 压缩和 128 MiB 解压缩限制，这些限制mix_hex_tarball：unpack_docs/3 适用。已签名的注册表不涵盖 docs tarball，因此没有任何内容对其进行检查。注册表响应在检查签名之前也会解压缩，采用 Hex 供应商hex_core代码;该部分在 https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq中进行跟踪。此问题影响之前2.5.2的 0.11.2 hex：（CVE-2026-96618）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - hexpm hex における高度に圧縮されたデータの不適切な処理(データ増幅)の脆弱性により、信頼できないパッケージミラーが、mix deps.get、mix deps.update、mix hex.package fetch または mix hex.docs fetch を実行しているマシンのメモリまたはディスクスペースを消費することが可能です。Hex は、HEX_MIRROR_URL、HEX_MIRROR または mirror_url で構成されたミラーを信頼できないものとして扱います。ミラーに認証情報を送信せず、ミラーが偽造できないレジストリ署名とパッケージチェックサムをチェックします。いくつかの応答パスは、これらのチェックのいずれかが実行される前に、ミラーが送信する内容に比例してメモリまたはディスクを消費します。Hex.HTTP.request/5 は応答本文全体をメモリに読み取り込み、応答の Content-Encoding に gzip が含まれているときはいつでも、圧縮時または展開時のサイズに制限なく :zlib.gunzip/1 で展開します。Hex は圧縮された応答を求めないため、このステップを実行するかどうかはサーバーが判断します。これは、レジストリ、パッケージ、docs、API の応答に適用されます。パッケージ tarball にはダウンロードサイズ制限がありません。Hex 2.5.1 が tarball 全体をメモリに保持してそれをキャッシュに書き込み、開発ブランチがこれを一時ファイルにストリームします。16 MiB の tarball 制限は、ファイルが解凍されるときにのみチェックされます。その後、tarball は、チェックサムがレジストリと比較される前に、2.5.1 内の deps/<app> および開発ブランチの staging ディレクトリに解凍されます。 hex.docs フェッチを混合し、オフラインで hex.docs を混合します docs がないときは、docs tarball をディスクに書き込み、16 MiB 圧縮および 128 MiB 展開のmix_hex_tarball制限なしで :mix_hex_erl_tar.extract/2 で展開します。unpack_docs/3が該当します。署名されたレジストリは docs tarball をカバーしないため、何もチェックされません。レジストリ応答も、署名がチェックされる前に、Hex ベンダー hex_coreコードで展開されます。その部分は https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmqで追跡されています。この問題は、2.5.2 より前の 0.11.2 の hex: に影響を与えます。(CVE-2026-96618)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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-2026-96618)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
366675	Linux Distros 未修補弱點：CVE-2026-96618	Nessus	Misc.	10/16/2026	11/6/2026	low
366675	Linux Distros 未修补的漏洞：CVE-2026-96618	Nessus	Misc.	10/16/2026	11/6/2026	low
366675	Linux Distros のパッチ未適用の脆弱性: CVE-2026-96618	Nessus	Misc.	10/16/2026	11/6/2026	low
366675	Linux Distros Unpatched Vulnerability : CVE-2026-96618	Nessus	Misc.	10/16/2026	11/6/2026	low

Detections

Analytics

Plugins Search

low

low

low

low