CVE-2026-48702 in Rekor
요약
\~에 의해 VulDB • 2026. 08. 13.
Rekor는 소프트웨어 공급망 투명성 로그입니다. 버전 0.3.0부터 버전 1.5.2 이전까지, `pkg/types/alpine/apk.go`의 `Package.Unmarshal()` 함수는 APK 파일의 시그니처 및 제어 gzip 구성 요소를 메모리 내 버퍼로 분해 압축 해제할 때 총 분해 압축 해제의 크기를 제한하지 않습니다. 기존 `max_apk_metadata_size`(기본값 1MB) 체크는 분해 압축 해제가 완료된 후 개별 tar 엔트리 헤더 크기에만 적용되므로, 분해 폭탄(decompression bomb)이 무제한 힙 메모리를 소모하는 것을 방지하지 못합니다. 공격자는 약 1000:1의 비율로 압축되는 gzip 스트림(예: 압축된 2MB 영문자 → 분해 압축 해제 후 2GB)을 조작할 수 있습니다. 이를 Alpine `ProposedEntry`의 spec.package.content로 제출하면 서버는 요청 처리 중 전체 페이로드를 메모리에 분해 압축 해제하여, 서버의 recover() 미들웨어에서 포착할 수 없는 치명적인 Go 런타임 Out-of-Memory(메모리 부족) 오류 또는 OS OOM-kill을 유발합니다. 이 취약점은 두 개의 비인증 엔드포인트인 `POST /api/v1/log/entries (createLogEntry)` 및 `POST /api/v1/log/entries/retrieve (searchLogQuery)`를 통해 접근 가능합니다. 둘 다 `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`를 호출하며, 여기서 무제한 분해 압축 해제가 수행됩니다. 버전 1.5.2에서 해당 문제가 패치되었습니다. 효과적인 우회 방법은 없습니다. `max_request_body_size` 설정은 약 1000:1의 압축 비율로 인해 노출을 줄이지만 제거하지는 못합니다(1MB 본문 제한도 여전히 약 1GB 힙 할당을 허용함). `max_apk_metadata_size` 설정은 이 취약점에 영향을 미치지 않습니다. 체크가 분해 압축 해제 후에 적용되기 때문입니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.