CVE-2026-48702 в Ubuntu: DoS через бомбу декомпрессии в Rekor

CVE: CVE-2026-48702
Продукт: Ubuntu
Дата публикации: 13.08.2026
Критичность: HIGH
CVSS: 7.5 (3.1)
EPSS: 0,46%; процентиль 38,37%
CISA KEV: нет подтверждения в каталоге CISA KEV

Краткое описание​

Уязвимость CVE-2026-48702 затрагивает пакет rekor в Ubuntu 26.04 LTS. Ошибка позволяет злоумышленнику вызвать отказ в обслуживании (DoS) путем отправки специально сформированного сжатого файла APK, который приводит к исчерпанию оперативной памяти сервера. Уязвимость существует в версиях от 0.3.0 до 1.5.1. Исправление доступно в версии 1.5.2. Временных обходных путей не существует.

Основные характеристики​

CVE-2026-48702 классифицируется как уязвимость типа «бомба декомпрессии» (CWE-770). Она затрагивает компонент Rekor — прозрачный журнал цепочки поставок программного обеспечения. Ошибка заключается в отсутствии ограничения на размер данных после распаковки gzip-архивов внутри APK-файлов. Это позволяет атакующему отправить небольшой по объему запрос, который при распаковке потребляет гигабайты оперативной памяти, приводя к падению процесса сервера или его принудительному завершению операционной системой (OOM-kill). Уязвимость затрагивает Ubuntu 26.04 LTS (ESM Apps).

Какие продукты и версии затронуты​

Уязвимы следующие компоненты в экосистеме Ubuntu:

• Ubuntu 26.04 LTS (Pro/ESM Apps): Пакет rekor версий от 0.3.0 до 1.5.1.
  
  • Бинарный пакет: rekor версии 1.5.0-1ubuntu0.26.04.1~esm1.
    
  • Бинарный пакет: golang-github-sigstore-rekor-dev версии 1.5.0-1ubuntu0.26.04.1~esm1.
    

Исправленная версия: rekor 1.5.2 и выше.

Причина уязвимости​

Причиной уязвимости является логическая ошибка в функции Package.Unmarshal() в файле pkg/types/alpine/apk.go. При обработке APK-файлов функция распаковывает gzip-члены (подписи и контрольные данные) во внутренние буферы памяти без проверки итогового размера распакованных данных.

Существующая проверка max_apk_metadata_size (по умолчанию 1 МБ) применяется только к размеру заголовков отдельных записей tar-архива после того, как декомпрессия уже завершена. Следовательно, эта проверка не предотвращает выделение огромного объема памяти на этапе распаковки gzip-потока. Атакующий может использовать коэффициент сжатия ~1000:1, чтобы превратить небольшой запрос в гигабайты данных в памяти.

Как работает атака​

Механизм атаки основан на эксплуатации неограниченной декомпрессии:

1. Атакующий создает gzip-поток с высоким коэффициентом сжатия (например, 2 МБ сжатых нулей, которые распаковываются в 2 ГБ данных).
   
2. Этот поток встраивается в APK-файл.
   
3. APK-файл передается в поле spec.package.content в структуре ProposedEntry типа Alpine.
   
4. Сервер Rekor обрабатывает запрос, вызывая цепочку функций: V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData).
   
5. Функция apk.Unmarshal выполняет полную распаковку gzip-данных в оперативную память.
   
6. Из-за отсутствия лимита на размер распакованных данных, память сервера исчерпывается.
   
7. Происходит фатальная ошибка среды выполнения Go (out-of-memory) или операционная система завершает процесс (OOM-kill). Механизм recover() в сервере не может перехватить эту ошибку, так как она происходит на уровне выделения памяти или на уровне ядра ОС.
   

Условия успешной эксплуатации​

Для эксплуатации уязвимости требуются следующие условия:

• Доступ к сети: Уязвимые конечные точки доступны из сети (интернет или внутренняя сеть).
  
• Отсутствие аутентификации: Атакующему не требуется учетная запись или токены доступа. Уязвимые конечные точки (POST /api/v1/log/entries и POST /api/v1/log/entries/retrieve) являются неаутентифицированными.
  
• Наличие уязвимой версии: Сервер должен работать на версии Rekor от 0.3.0 до 1.5.1.
  
• Поддержка Alpine APK: Запрос должен быть сформирован как запись типа Alpine, чтобы активировать путь кода, обрабатывающий APK-файлы.
  

Возможный сценарий атаки​

Сценарий атаки на отказ в обслуживании (DoS):

1. Атакующий идентифицирует публично доступный экземпляр Rekor, работающий на Ubuntu 26.04 LTS с уязвимой версией пакета.
   
2. Генерируется вредоносный APK-файл, содержащий gzip-поток с высоким коэффициентом сжатия (например, 1 МБ сжатых данных, распаковывающихся в 1 ГБ).
   
3. Отправляется HTTP-запрос POST на конечную точку /api/v1/log/entries (создание записи) или /api/v1/log/entries/retrieve (поиск).
   
4. В теле запроса поле spec.package.content содержит вредоносный APK.
   
5. Сервер принимает запрос и начинает обработку.
   
6. В процессе канонизации записи сервер распаковывает APK.
   
7. Оперативная память сервера быстро исчерпывается.
   
8. Процесс Rekor завершается с ошибкой или убивается ядром Linux.
   
9. Сервис становится недоступен для легитимных пользователей до перезапуска процесса или восстановления системы.
   

Есть ли публичный эксплойт​

На момент публикации официальных данных подтвержденных случаев эксплуатации в дикой природе (wild exploitation) не зафиксировано. Однако техническое описание уязвимости и вектор атаки полностью раскрыты в отчете безопасности. Создание PoC (proof-of-concept) не требует сложных инструментов, так как достаточно сформировать gzip-архив с высоким коэффициентом сжатия и отправить его на уязвимый эндпоинт. Отсутствие публичного эксплойта в репозиториях не означает отсутствие риска, учитывая простоту механизма и отсутствие аутентификации.

Признаки эксплуатации​

Специфичных индикаторов компрометации (IOC), таких как уникальные хеши вредоносных файлов, для этой уязвимости не существует, так как атака направлена на отказ в обслуживании, а не на внедрение вредоносного кода. Однако можно отслеживать следующие неспецифичные признаки:

• Резкий рост потребления памяти: Мониторинг процесса rekor показывает аномальный рост использования RAM перед падением.
  
• OOM-kill в журналах ядра: Записи в /var/log/kern.log или dmesg, указывающие на принудительное завершение процесса rekor из-за нехватки памяти.
  
• Падения сервиса: Частые перезапуски контейнера или сервиса Rekor.
  
• Аномальные запросы: HTTP-запросы к /api/v1/log/entries с необычно большим соотношением размера тела запроса к ожидаемому размеру метаданных (хотя само тело запроса может быть небольшим, эффект в памяти — большим).
  

Как обнаружить атаку​

Для обнаружения признаков атаки или наличия уязвимой версии рекомендуется:

1. Проверка версии пакета: Убедиться, что установленная версия rekor не входит в диапазон уязвимых версий.
   
2. Мониторинг ресурсов: Настроить алерты на резкое увеличение потребления памяти процессом rekor.
   
3. Анализ журналов системы: Регулярно проверять системные журналы на наличие сообщений об OOM-killer.
   
4. Анализ журналов приложения: Искать ошибки runtime: out of memory в логах Rekor.
   
5. Сканирование уязвимостей: Использовать инструменты типа ubuntu-security-status для проверки наличия незакрытых уязвимостей в системе.
   

Как проверить свою версию​

Для проверки версии установленного пакета rekor в Ubuntu используйте следующие команды:

# Проверка версии пакета rekor
apt-cache policy rekor

# Альтернативный способ проверки версии и статуса обновлений
ubuntu-security-status

# Проверка версии ОС (для контекста)
cat /etc/os-release

# Проверка версии ядра (для контекста)
uname -r

В выводе apt-cache policy rekor обратите внимание на строку Installed:. Если версия ниже 1.5.2 (например, 1.5.0-1ubuntu0.26.04.1~esm1), система уязвима.

Исправление​

Единственным эффективным способом устранения уязвимости является обновление пакета rekor до версии 1.5.2 или выше.

Для Ubuntu 26.04 LTS (ESM Apps) выполните:

sudo apt update
sudo apt install --only-upgrade rekor

После обновления убедитесь, что версия пакета соответствует исправленной (1.5.2+). Перезапустите сервис Rekor, чтобы изменения вступили в силу:

sudo systemctl restart rekor

Если Rekor запущен в контейнере, обновите образ контейнера до версии, содержащей исправленный пакет, и перезапустите контейнер.

Временные меры защиты​

Официальные источники указывают, что эффективных временных обходных путей не существует.

• Ограничение размера тела запроса (max_request_body_size): Установка лимита на размер входящего HTTP-запроса (например, 1 МБ) не устраняет уязвимость. Из-за коэффициента сжатия ~1000:1, запрос в 1 МБ может привести к выделению ~1 ГБ памяти, что все равно может вызвать OOM-kill на серверах с ограниченным объемом RAM.
  
• Настройка max_apk_metadata_size: Изменение этого параметра не влияет на уязвимость, так как проверка применяется после декомпрессии, когда память уже выделена.
  

Единственным частичным смягчением может быть жесткое ограничение размера тела запроса на уровне обратного прокси (Nginx, Apache) до минимально возможного значения, которое не позволит даже малому сжатому архиву вызвать критическое исчерпание памяти, но это может нарушить легитимную работу сервиса. Рекомендуется как можно скорее применить патч.

Как проверить устранение уязвимости​

После обновления выполните следующие шаги для подтверждения исправления:

1. Проверка версии:
   
   

   apt-cache policy rekor

   
   Убедитесь, что установленная версия равна или выше 1.5.2.
   
2. Проверка статуса безопасности:
   
   

   ubuntu-security-status

   
   Убедитесь, что CVE-2026-48702 больше не отображается в списке активных уязвимостей.
   
3. Функциональное тестирование: Убедитесь, что сервис Rekor корректно обрабатывает легитимные запросы на создание и поиск записей.
   
4. Мониторинг: В течение нескольких дней после обновления наблюдайте за потреблением памяти процессом rekor и отсутствием ошибок OOM в системных журналах.
   

Вывод​

CVE-2026-48702 представляет собой серьезную угрозу для доступности сервисов Rekor, развернутых в Ubuntu 26.04 LTS. Уязвимость позволяет любому злоумышленнику вызвать отказ в обслуживании без аутентификации, используя простую технику бомбы декомпрессии. Отсутствие эффективных временных обходных путей делает немедленное обновление пакета rekor до версии 1.5.2 критически важным. Администраторам следует также настроить мониторинг потребления памяти и журналов ядра для раннего обнаружения попыток атаки.

Официальные источники​

1. NVD — CVE-2026-48702
   
2. Ubuntu OSV — CVE-2026-48702
   
3. FIRST EPSS — CVE-2026-48702
   

История обновлений статьи​

• 14.08.2026 — Опубликована первая версия материала.
  
• 17.08.2026 — Уточнены сведения об уязвимых версиях, оценке риска или исправлении.
  
• 22.08.2026 — Уточнены сведения об уязвимых версиях, оценке риска или исправлении.