CVE-2026-105274

NiskieCVSS 2.1

Opublikowano: 12/10/2026(UTC)Zaktualizowano: 15/10/2026(UTC)Przetłumaczono: 13/10/2026(UTC)NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko

0.42%

Percentyl 35 - wyżej niż 35% wszystkich znanych CVE

Streszczenie

Podatność nieprawidłowego obsługiwania wysoko skompresowanych danych (Data Amplification) w hex_core pozwala niezaufanemu mirrorowi repozytorium lub serwerowi odpowiadającemu na żądania API hex_core na wyczerpanie pamięci maszyny Erlang VM uruchamiającej hex_core. Ten sam kod jest sprzedawany w Hex (mix_hex_repo, mix_hex_api) i rebar3 (r3_hex_repo, r3_hex_api). Funkcje hex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 i hex_repo:get_policy/2 dekompresują odpowiedź rejestru za pomocą zlib:gunzip/1 i dekodują podpisaną kopertę przed weryfikacją podpisu. Mirror nie ma klucza prywatnego repozytorium, ale wybiera skompresowane bajty, więc mała odpowiedź dekompresuje się do koperty o dowolnym rozmiarze, zanim kontrola podpisu ją odrzuci. hex_api dekoduje odpowiedzi z typem treści application/vnd.hex+erlang przez hex_safe_binary_to_term:safe_binary_to_term/1, który wywołuje binary_to_term(Binary, [safe]). Opcja safe zapobiega tworzeniu atomów, ale akceptuje skompresowane termy i nie ogranicza rozmiaru zdekodowanego termu, a kontrola odrzucająca funkcje i porty działa po zbudowaniu termu. Poprawka dla CVE-2026-21619 dodała opcję safe i tę kontrolę bez ograniczania zdekodowanego rozmiaru. Problem dotyczy rebar3: od 3.9.1 przed 3.27.3; hex: od 2.1.0 przed 2.5.2; hex_core: od 0.1.0 przed 0.20.0.

Ocena ryzyka

Organizacja może być narażona na ataki DoS polegające na wyczerpaniu pamięci, co może prowadzić do awarii systemu lub niedostępności usług. Atakujący może wykorzystać niezaufane mirror repozytorium do spowodowania znacznego obciążenia pamięci.

Rekomendacja

Zaleca się natychmiastowe zaktualizowanie hex_core, Hex i rebar3 do najnowszych wersji zawierających poprawki. Należy również korzystać wyłącznie z zaufanych mirrorów repozytoriów.

Inne podatności w hex_core

CVE-2026-103502Średnie
Podatność w bibliotece hex_core (do wersji 0.20.0) polega na nieprawidłowej walidacji certyfikatów podczas połączeń HTTPS. Atakujący, który może przechwycić ruch sieciowy, może podszyć się pod serwery takie jak hex.pm, repo.hex.pm lub inne repozytoria i serwery API, gdy program używa domyślnego adaptera HTTP na Erlang/OTP 24 lub OTP 25 (gdy nie można załadować certyfikatów CA).

Oryginalny opis (angielski, źródło NVD)

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in hexpm hex_core allows an untrusted repository mirror, or a server answering hex_core's API requests, to exhaust the memory of the Erlang VM running hex_core. The same code is vendored in Hex (mix_hex_repo, mix_hex_api) and rebar3 (r3_hex_repo, r3_hex_api). hex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 and hex_repo:get_policy/2 decompress the registry response with zlib:gunzip/1 and decode the signed envelope before verifying its signature. A mirror doesn't have the repository's private key, but it chooses the compressed bytes, so a small response decompresses into an envelope of any size before the signature check rejects it. hex_api decodes responses with the application/vnd.hex+erlang content type through hex_safe_binary_to_term:safe_binary_to_term/1, which calls binary_to_term(Binary, [safe]). The safe option prevents atom creation, but it accepts compressed terms and doesn't limit the size of the decoded term, and the check that rejects functions and ports runs after the term has been built. The fix for CVE-2026-21619 added the safe option and that check without bounding the decoded size. This issue affects rebar3: from 3.9.1 before 3.27.3; hex: from 2.1.0 before 2.5.2; hex_core: from 0.1.0 before 0.20.0.

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS