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 Distros 未修補弱點：CVE-2026-96618

low Nessus Plugin ID 366675

版本 1.2