CVE-2026-96618 in hex
요약
\~에 의해 VulDB • 2026. 10. 12.
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는 자격 증명을 전송하지 않으며, 미러가 위조할 수 없는 레지스트리 서명과 패키지 체크섬을 확인합니다. 그러나 이러한 검사 전에 미러에서 보내는 데이터의 양에 비례하여 메모리나 디스크를 소비하는 여러 응답 경로가 존재합니다.
Hex.HTTP.request/5 함수는 응답 본문 전체를 메모리에 읽어들인 후, 응답의 Content-Encoding이 gzip을 포함할 경우 :zlib.gunzip/1로 압축 해제합니다. 이때 압축된 크기 또는 압축 해지된 크기에 대한 제한은 없습니다. Hex는 압축된 응답을 요청하지 않으므로 서버가 이 단계를 실행할지 여부를 결정합니다. 이는 레지스트리, 패키지, 문서 및 API 응답에 적용됩니다.
패키지 tarball에는 다운로드 크기 제한이 없습니다. Hex 2.5.1에서는 전체 tarball을 메모리에 유지하고 캐시에 기록하며, 개발 브랜치에서는 임시 파일로 스트림 처리합니다. 16 MiB의 tarball 제한은 파일이 압축 해제될 때만 확인됩니다. 그 후 tarball은 deps/<app>(2.5.1 버전) 또는 개발 브랜치의 스테이징 디렉토리에 압축 해제되며, 레지스트리와 체크섬을 비교하기 전에 이러한 작업이 수행됩니다.
mix hex.docs fetch 및 docs가 누락된 경우 mix hex.docs offline는 문서 tarball을 디스크에 작성하고 :mix_hex_erl_tar.extract/2를 사용하여 압축합니다. 이때 mix_hex_tarball:unpack_docs/3 함수에서 적용되는 16 MiB의 압축 제한과 128 MiB의 압축 해제 제한이 적용되지 않습니다. 서명된 레지스트리는 문서 tarball을 포함하지 않으므로 이를 검증하는 절차가 없습니다.
레지스트리 응답도 hex_core 코드(Hex가 벤더링함)에서 서명이 확인되기 전에 압축 해제됩니다. 이 부분은 https://github.com/hexpm/hex_core/security/advisories/GHSA-7c4r-cgf9-9jmq에서 추적되고 있습니다.
이 이슈는 0.11.2부터 2.5.2 미만 버전의 hex에 영향을 미칩니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.