CVE-2026-105274 in hex
요약
\~에 의해 VulDB • 2026. 10. 12.
hexpm hex_core의 과도하게 압축된 데이터 처리 불일치(데이터 증폭) 취약점으로 인해, 신뢰할 수 없는 리포지토리 미러 또는 hex_core API 요청에 응답하는 서버가 Erlang VM의 메모리를 고갈시킬 수 있습니다. 동일한 코드는 Hex(mix_hex_repo, mix_hex_api) 및 rebar3(r3_hex_repo, r3_hex_api)에서 번들링되어 사용됩니다.
hex_repo:get_names/1, hex_repo:get_versions/1, hex_repo:get_package/2 및 hex_repo:get_policy/2는 zlib:gunzip/1을 사용하여 레지스트리 응답의 압축을 해제하고 서명 검증을 수행하기 전에 서명된 엔벨로프를 디코딩합니다. 미러에는 리포지토리의 개인 키가 없지만, 압축된 바이트를 선택할 수 있으므로 작은 응답이 서명 확인에서 거부되기 전에 임의 크기의 엔벨로프로 확장됩니다.
hex_api는 application/vnd.hex+erlang 콘텐츠 타입을 통해 hex_safe_binary_to_term:safe_binary_to_term/1을 사용하여 응답을 디코딩하며, 이는 binary_to_term(Binary, [safe])를 호출합니다. safe 옵션은 원자(atom) 생성을 방지하지만 압축된 항(term)은 허용하고 디코딩된 항의 크기를 제한하지 않으며, 함수와 포트를 거부하는 검사는 항이 구축된 후에 실행됩니다. CVE-2026-21619에 대한 수정 사항에는 safe 옵션과 해당 검증이 포함되었으나 디코딩된 크기는 제한되지 않았습니다.
이 문제는 다음 제품에 영향을 미칩니다: rebar3(3.9.1 이상), hex(2.1.0부터 2.5.2 미만), hex_core(0.1.0부터 0.20.0 미만).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.