CVE: CVE-2026-48702
Продукт: Ubuntu
Дата публикации: 13.08.2026
Критичность: HIGH
CVSS: 7.5 (3.1)
EPSS: 0,46%; процентиль 38,10%
CISA KEV: нет подтверждения в каталоге CISA KEV
Краткое описание
Уязвимость CVE-2026-48702 в компоненте Rekor (поставщик цепочки поставок программного обеспечения) позволяет атакующему вызвать отказ в обслуживании (DoS) путем исчерпания памяти сервера. Проблема затрагивает Ubuntu Pro 26.04 LTS. Ошибка связана с неограниченным распаковкой gzip-архивов в функции Package.Unmarshal(), что приводит к утечке памяти или принудительному завершению процесса ядром (OOM-kill). Исправление доступно в версии 1.5.2 пакета rekor.
Основные характеристики
CVE-2026-48702 классифицируется как уязвимость типа «отказ в обслуживании» (DoS) с высоким уровнем серьезности (CVSS 7.5). Она затрагивает сервер Rekor, используемый для обеспечения прозрачности цепочки поставок программного обеспечения. Уязвимость существует в версиях от 0.3.0 до 1.5.1. В Ubuntu Pro 26.04 LTS уязвимым является пакет rekor версии 1.5.0-1ubuntu0.26.04.1~esm1. Атака не требует аутентификации и может быть выполнена через публичные API-эндпоинты. Механизм уязвимости основан на CWE-770 (Allocation of Resources Without Limits or Throttling).
Какие продукты и версии затронуты
В экосистеме Ubuntu уязвимость подтверждена для Ubuntu Pro 26.04 LTS. Затронут исходный пакет rekor. Конкретные бинарные пакеты, содержащие уязвимый код: rekor версии 1.5.0-1ubuntu0.26.04.1~esm1 и golang-github-sigstore-rekor-dev версии 1.5.0-1ubuntu0.26.04.1~esm1. Эти пакеты распространяются через канал ESM Apps (Extended Security Maintenance). Другие версии Ubuntu или стандартные репозитории без подписки Pro могут не содержать этого пакета или иметь другую версию, однако данные о других дистрибутивах Ubuntu в предоставленных источниках отсутствуют.
Причина уязвимости
Корневой причиной уязвимости является отсутствие проверки общего размера данных после распаковки в функции Package.Unmarshal() в файле pkg/types/alpine/apk.go. При обработке APK-файлов (Alpine Package) сервер распаковывает gzip-члены (подписи и контрольные данные) непосредственно в буферы памяти. Существующая проверка max_apk_metadata_size (по умолчанию 1 МБ) применяется только к размеру заголовков отдельных записей tar-архива после завершения распаковки. Это означает, что проверка не ограничивает объем памяти, выделяемый под сам контент gzip-архива. Атакующий может создать «бомбу из сжатых данных» (decompression bomb) с коэффициентом сжатия ~1000:1, что приводит к выделению гигабайтов памяти при отправке мегабайтного запроса.
Как работает атака
Атака реализуется путем отправки специально сформированного HTTP-запроса на публичные API-эндпоинты Rekor. Атакующий создает gzip-поток, который при распаковке занимает значительно больше места, чем исходный файл (например, 2 МБ сжатых данных превращаются в 2 ГБ в памяти). Этот payload передается в поле spec.package.content в рамках Alpine ProposedEntry. При обработке запроса сервер вызывает цепочку функций: V001Entry.Canonicalize() -> fetchExternalEntities() -> apk.Unmarshal(packageData). Функция apk.Unmarshal выполняет распаковку без ограничения итогового размера, заполняя кучу (heap) памяти. Поскольку ошибка происходит на уровне выделения памяти Go runtime, она вызывает фатальную ошибку Out-Of-Memory (OOM), которую невозможно перехватить стандартным middleware recover(). В результате процесс сервера завершается ядром операционной системы (OOM-kill).
Условия успешной эксплуатации
Для успешной эксплуатации не требуется аутентификация или учетные данные. Атакующий должен иметь сетевой доступ к публичным API-эндпоинтам Rekor. Целевыми являются два эндпоинта: POST /api/v1/log/entries (createLogEntry) и POST /api/v1/log/entries/retrieve (searchLogQuery). Атакующему необходимо знать структуру Alpine APK и уметь формировать gzip-архивы с высоким коэффициентом сжатия. Также требуется понимание того, что параметр max_request_body_size на уровне веб-сервера или прокси не защищает от этой уязвимости, так как даже небольшой размер тела запроса (например, 1 МБ) может привести к выделению ~1 ГБ памяти из-за коэффициента сжатия.
Возможный сценарий атаки
Атакующий идентифицирует публичный экземпляр Rekor, работающий на Ubuntu Pro 26.04 LTS с уязвимой версией пакета. Он создает gzip-архив, содержащий повторяющиеся данные (например, нули), сжимая их до минимального размера. Затем он формирует HTTP POST-запрос к эндпоинту /api/v1/log/entries, вставляя сжатый архив в поле spec.package.content. При получении запроса сервер Rekor начинает распаковку данных в память. Из-за отсутствия лимита на размер распакованного буфера, память сервера быстро исчерпывается. Процесс Rekor падает с ошибкой OOM. Если атакующий повторяет эту операцию или атакует несколько узлов в кластере, это приводит к полному отказу сервиса (DoS). Восстановление требует перезапуска сервиса, но без обновления пакета атака может быть повторена.
Есть ли публичный эксплойт
В предоставленных источниках нет информации о наличии публичных эксплойтов (PoC) или подтвержденных случаях эксплуатации в дикой природе. Однако механика уязвимости хорошо документирована, и создание proof-of-concept кода является тривиальной задачей для любого разработчика, знакомого с Go и gzip. Отсутствие публичного эксплойта не означает отсутствие риска, особенно учитывая, что атака не требует аутентификации и может быть автоматизирована.
Признаки эксплуатации
Специфичные индикаторы компрометации (IOC) для этой уязвимости не определены, так как атака направлена на отказ в обслуживании, а не на внедрение вредоносного кода. Общие признаки атаки включают: внезапное завершение процесса Rekor с кодом ошибки OOM-kill в системных журналах; аномальное увеличение потребления памяти процессом Rekor непосредственно перед падением; всплеск количества запросов к эндпоинтам /api/v1/log/entries и /api/v1/log/entries/retrieve с необычно маленькими телами запросов, но приводящих к высоким нагрузкам на память. Эти признаки неспецифичны и могут быть вызваны другими причинами, но в контексте известной уязвимости должны рассматриваться как подозрительные.
Как обнаружить атаку
Для обнаружения атаки или проверки состояния системы администраторы должны мониторить системные журналы (dmesg, syslog) на наличие сообщений об OOM-kill процесса rekor. Также полезно отслеживать метрики потребления памяти процессом Rekor. Внезапные скачки использования heap-памяти могут указывать на попытку атаки. Проверка конфигурации сервера на наличие ограничений размера запроса (max_request_body_size) необходима, но следует помнить, что эти ограничения не являются достаточной защитой. Анализ логов доступа веб-сервера на предмет частых запросов к API-эндпоинтам Rekor от неизвестных IP-адресов также может помочь выявить подозрительную активность.
Как проверить свою версию
Для проверки версии установленного пакета rekor в Ubuntu используйте следующие команды:
Bash:
apt-cache policy rekorЭта команда покажет установленную версию и доступные обновления. Уязвимой является версия 1.5.0-1ubuntu0.26.04.1~esm1. Также можно проверить версию ядра и информацию о системе:
Bash:
uname -r
cat /etc/os-releaseДля получения статуса безопасности системы используйте:
Bash:
ubuntu-security-statusЕсли установлен пакет версии 1.5.0-1ubuntu0.26.04.1~esm1, система уязвима.
Исправление
Единственным эффективным способом устранения уязвимости является обновление пакета rekor до версии 1.5.2 или выше. В Ubuntu Pro 26.04 LTS исправление доступно через канал ESM Apps. Выполните следующие команды для обновления:
Bash:
sudo apt update
sudo apt install rekorПосле обновления убедитесь, что версия пакета соответствует исправленной (1.5.2 или новее). Перезапустите сервис Rekor, чтобы изменения вступили в силу. Если вы используете контейнерные образы, пересоберите их с использованием обновленного пакета.
Временные меры защиты
Эффективных временных мер (workarounds) для этой уязвимости не существует. Установка параметра max_request_body_size на уровне веб-сервера или прокси снижает вероятность атаки, но не устраняет риск полностью. Из-за высокого коэффициента сжатия (~1000:1), даже ограничение в 1 МБ для тела запроса позволяет атакующему выделить ~1 ГБ памяти на сервере, что может привести к OOM-kill. Параметр max_apk_metadata_size не влияет на эту уязвимость, так как проверка применяется после распаковки. Единственная надежная защита — немедленное обновление пакета.
Как проверить устранение уязвимости
После применения обновления проверьте версию пакета:
Bash:
apt-cache policy rekorУбедитесь, что установленная версия (Installed) равна или выше 1.5.2. Также проверьте статус безопасности системы:
Bash:
ubuntu-security-statusЭта команда должна показать, что CVE-2026-48702 исправлена. Перезапустите сервис Rekor и проверьте логи на отсутствие ошибок OOM. Если сервис работает стабильно и версия пакета обновлена, уязвимость устранена.
Вывод
CVE-2026-48702 представляет серьезную угрозу для доступности сервисов Rekor, развернутых в Ubuntu Pro 26.04 LTS. Уязвимость позволяет атакующему вызвать отказ в обслуживании путем исчерпания памяти сервера через специально сформированные gzip-архивы. Отсутствие эффективных временных мер делает немедленное обновление пакета rekor критически важным. Администраторы должны проверить версии установленных пакетов, применить обновления и мониторить систему на признаки атак. Игнорирование этой уязвимости может привести к длительным простоям сервиса.
Официальные источники
История обновлений статьи
- 14.08.2026 — Опубликована первая версия материала.
- 17.08.2026 — Уточнены сведения об уязвимых версиях, оценке риска или исправлении.
Последнее редактирование:
