🇰🇷 한글 설명
hexpm hex_core에서 고도로 압축된 데이터를 처리할 때 발생하는 데이터 증폭 취약점입니다. 신뢰할 수 없는 저장소 미러나 서버가 압축된 응답을 보낼 경우, 서명 검증 전 단계에서 Erlang VM의 메모리를 고갈시켜 서비스 거부(DoS)를 유발할 수 있습니다.
💡 쉬운 설명
작은 크기의 압축 파일을 보냈을 때 컴퓨터가 이를 풀면서 엄청나게 큰 용량으로 불어나게 만들어 메모리를 가득 채우는 공격입니다. 이로 인해 프로그램이 멈추거나 서버가 다운될 수 있습니다.
🇺🇸 원문 (English)
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.
📍 영향받는 시스템
rebar3 < 3.27.3, hex < 2.5.2, hex_core < 0.20.0
⚔️ 공격 벡터
악의적인 미러 서버나 API 응답 서버가 압축 해제 시 메모리 폭증을 유도하는 특수하게 제작된 압축 데이터를 전송함
🛡️ 대응 방법
rebar3 3.27.3 이상, hex 2.5.2 이상, hex_core 0.20.0 이상 버전으로 업데이트
🔧 검증 코드
명령어 실행 결과로 취약점이 해결된 버전 번호가 출력되면 안전합니다.
rebar3 --version | grep -E '3\.(2[7-9]|\d{2,})' || hex --version | grep -E '2\.5\.2' || hex_core --version | grep -E '0\.20\.0'
💻 영향받는 소프트웨어
IBM WebSphere Application Server