CVE-2026-48702 in Rekor
Сводка
по VulDB • 13.08.2026
Rekor — это журнал прозрачности цепочки поставок программного обеспечения. Начиная с версии 0.3.0 и до версии 1.5.2 включительно функция `Package.Unmarshal()` в файле `pkg/types/alpine/apk.go` распаковывает сигнатурные и контрольные gzip-компоненты APK-файла во внутренние буферы памяти без ограничения общего размера распакованных данных. Существующая проверка `max_apk_metadata_size` (по умолчанию 1 МБ) применяется только к размерам заголовков отдельных элементов tar после завершения распаковки, поэтому она не предотвращает использование неограниченной памяти в куче при атаке типа «бомба сжатия» (decompression bomb). Злоумышленник может создать gzip-поток со степенью сжатия около 1000:1 (например, 2 МБ сжатых нулей превращаются в 2 ГБ распакованных данных). При передаче такого потока как `spec.package.content` в Alpine `ProposedEntry` сервер во время обработки запроса распаковывает весь полезный груз в память, что вызывает фатальную ошибку нехватки памяти (out-of-memory) среды выполнения Go или принудительное завершение процесса операционной системой по причине OOM-kill; данная ситуация не может быть перехвачена промежуточным ПО `recover()` сервера. Уязвимость доступна через два неподтвержденных аутентификацией эндпоинта: `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 (лимит тела запроса в 1 МБ все еще позволяет выделить около 1 ГБ памяти в куче). Настройка `max_apk_metadata_size` не влияет на данную уязвимость, поскольку проверка применяется после завершения распаковки.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.