CVE-2026-123710: неаутентифицированная подмена ключа подписи в Red Hat Quay

Red Hat исправила уязвимость CVE-2026-123710 в Red Hat Quay. Неаутентифицированный клиент может получить анонимный токен реестра с контролируемой audience, предъявить его к эндпоинту ротации служебных ключей и поставить собственный ключ подписи без срока действия. После этого поддельные токены принимаются для любого репозитория: атакующий читает и записывает приватные образы и подменяет теги. Red Hat присвоила ошибке критический уровень, оценка CVSS 3.1 - 9.8. Исправления вышли в RHSA-2026:99019 и других выпусках, а до обновления доступ к эндпоинту ротации ключей стоит закрыть от недоверенных клиентов.

Что позволяет атака

Red Hat Quay - корпоративный реестр контейнерных образов на базе Project Quay. Компании хранят в нём образы своих приложений, а Kubernetes и другие платформы забирают их оттуда при развёртывании. Доступ к приватным образам выдают токены реестра, которые подписывает служебный ключ Quay.

Атака состоит из двух шагов. Сначала клиент без учётной записи получает анонимный токен через стандартный механизм аутентификации реестра. Audience у этого токена атакующий задаёт сам. Затем он отправляет токен в эндпоинт ротации служебных ключей /keys. Проверка подлинности там сводится к тому, что JWT подписан уже одобренным ключом с ожидаемыми audience и issuer. Отдельной проверки, что перед нами именно учётные данные для ротации, нет, поэтому анонимный токен проходит.

Дальше клиент устанавливает свой ключ подписи. Ключ наследует статус одобренного и создаётся без срока действия. Токены, подписанные этим ключом, Quay принимает для любого репозитория. Итог - чтение и запись приватных образов и замена тегов. Подмена тегов опасна сама по себе: развёртывание может получить чужой образ под знакомым именем.

Ошибку классифицировали как CWE-1287, некорректная проверка типа входных данных. Вектор сетевой, привилегии и участие пользователя не нужны, влияние на конфиденциальность, целостность и доступность высокое. Именно поэтому оценка CVSS 3.1 достигает 9.8, а Red Hat относит ошибку к критическому уровню. Уязвимость нашёл Dave O'Connor из Red Hat, компания получила сообщение 6 ноября, публично ошибка раскрыта 11 ноября.

Служебный ключ подписи - корневой элемент доверия реестра. Пока ключ действителен, Quay не отличает токен, выданный законному клиенту, от токена, подписанного ключом атакующего. Ротация задумана как операция администратора: она нужна при плановой смене ключа или при подозрении на компрометацию. Проверка типа входных данных должна была отделить такие операции от обычных токенов, но в уязвимой версии этого не было.

Условия эксплуатации

Атака идёт по сети и не требует учётной записи. Ключевое условие одно: эндпоинт /keys должен быть доступен недоверенным клиентам. Если прокси или балансировщик отдаёт его наружу, любой клиент может попробовать ротацию. Деплойменты, где служебный эндпоинт закрыт и доступен только внутренним компонентам, в зону риска не попадают.

Второй элемент - анонимный токен. Его выдают штатно, это не ошибка и не обход аутентификации. Отдельной сложности нет и с audience: анонимный токен формируется по запросу клиента, поэтому подставить нужное значение не составляет труда. От атакующего не требуется ни учётная запись, ни взаимодействие с администратором, ни особые права. Достаточно умения отправить HTTP-запрос и знать адрес реестра.

Затронутые версии

Уязвимы версии Project Quay младше 3.9.28, а также ветки 3.10, 3.12 и 3.14-3.18 до исправленных сборок: 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 и 3.18.3. Ветки 3.11 и 3.13 в записи CVE не перечислены.

Red Hat выпустила errata для поддерживаемых веток. RHSA-2026:99019 закрывает Red Hat Quay 3.18.3, остальные номера RHSA перечислены в записи CVE и в бюллетене вендора. Исправленные сборки вышли 11 ноября одновременно с публикацией CVE. Обновляться нужно на исправленную сборку своей ветки, а не на произвольную последнюю версию: перенос через несколько мажорных веток потребует отдельной проверки совместимости.

Если обновиться нельзя

Временная мера у Red Hat одна: ограничить доступ к /keys на прокси или балансировщике, чтобы эндпоинт видели только доверенные внутренние компоненты. Это снимает сам вектор атаки, но не исправляет код.

Параллельно нужно проверить аудит-логи на события service_key_rotate и service_key_delete с пустым expiration_date и удалить незнакомые одобренные ключи. Важная оговорка: удаление ключа не будет окончательным до установки исправленной сборки, потому что анонимный запрос позволяет поставить новый ключ. Поэтому чистить ключи имеет смысл после закрытия /keys или вместе с обновлением.

Что проверить

Аудит стоит смотреть за весь период, когда уязвимая версия была доступна недоверенным клиентам. Ищите события ротации и удаления служебных ключей с пустым сроком действия, а также ключи, которых вы не добавляли.

Затем проверьте репозитории: необычные push и pull, изменения тегов, новые образы с неожиданными digest, обращения к приватным проектам из неизвестных источников. Если в логах есть подозрительные события, исходите из того, что подпись токенов могла быть скомпрометирована, и оцените, какие образы и теги могли подменить.

Порядок действий: закрыть /keys от недоверенных клиентов, обновиться до исправленной сборки своей ветки, проверить и почистить служебные ключи, затем просмотреть аудит и состояние репозиториев. Отдельно проверьте, какие образы и теги развёрнуты из этого реестра в продакшене: подмена тега могла затронуть не только сам Quay, но и то, что из него запускали. Для установок, которые получают образы Quay из registry.redhat.io, исправления приходят через errata вендора.

Что позволяет атака

Условия эксплуатации

Затронутые версии

Если обновиться нельзя

Что проверить

Ссылки