CVE-2026-96618 in hex
Zusammenfassung
von VulDB • 12.10.2026
Eine Schwachstelle für die unsachgemäße Verarbeitung stark komprimierter Daten (Data Amplification) in hexpm hex ermöglicht es einem nicht vertrauenswürdigen Paket-Spiegelserver, den Arbeitsspeicher oder den Festplattenspeicher des Systems zu erschöpfen, auf dem `mix deps.get`, `mix deps.update`, `mix hex.package fetch` oder `mix hex.docs fetch` ausgeführt wird.
Hex behandelt einen mit HEX_MIRROR_URL, HEX_MIRROR oder mirror_url konfigurierten Spiegelserver als nicht vertrauenswürdig: Es sendet keine Anmeldeinformationen daran und überprüft Registry-Signaturen sowie Paket-Checksummen, die der Spiegelserver nicht fälschen kann. Mehrere Antwortpfade verbrauchen jedoch Arbeitsspeicher oder Festplattenspeicher in einem Maße, das proportional zu dem ist, was der Spiegelserver sendet, bevor eine dieser Prüfungen durchgeführt wird.
Hex.HTTP.request/5 liest den gesamten Antwortkörper in den Speicher und dekomprimiert ihn mit :zlib.gunzip/1, wenn die Content-Encoding-Antwort gzip enthält; dabei gibt es keine Begrenzung für die komprimierte oder dekomprimierte Größe. Hex fordert keine komprimierten Antworten an, sodass der Server entscheidet, ob dieser Schritt ausgeführt wird. Dies gilt für Registry-, Paket-, Dokument- und API-Antworten.
Paket-Tarballs haben kein Download-Größenlimit. Hex 2.5.1 hält den gesamten Tarball im Speicher und schreibt ihn in den Cache; die Entwicklungsversion streamt ihn in eine temporäre Datei. Das Limit von 16 MiB für Tarballs wird erst geprüft, wenn die Datei entpackt wird. Der Tarball wird dann entpackt – in Version 2.5.1 nach deps/ und in der Entwicklungsversion in ein Staging-Verzeichnis –, bevor seine Checksummen mit denen der Registry verglichen werden.
`mix hex.docs fetch` sowie `mix hex.docs offline`, wenn Dokumente fehlen, schreiben den Dokument-Tarball auf die Festplatte und extrahieren ihn mit :mix_hex_erl_tar.extract/2 ohne die Limits von 16 MiB (komprimiert) und 128 MiB (dekomprimiert), die durch mix_hex_tarball:unpack_docs/3 angewendet werden. Die signierte Registry deckt keine Dokument-Tarballs ab, sodass diese nicht überprüft werden.
Registry-Antworten werden ebenfalls dekomprimiert, bevor ihre Signatur geprüft wird; dies geschieht im von Hex vendored hex_core-Code. Dieser Teil ist unter https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq nachverfolgt.
Dieses Problem betrifft hex: ab Version 0.11.2 bis vor 2.5.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.