Критична вразливість Red Hat Quay: хтось може читати та підміняти ваші контейнери

Що сталося

11 листопада 2026 року Red Hat опублікувала два критичні бюлетені безпеки для Red Hat Quay — корпоративного реєстру контейнерів, який компанії використовують для зберігання, керування та розповсюдження образів у розробці й продакшені. Обидві вразливості дозволяють зловмисникові отримати доступ до приватних образів інших команд або навіть підмінити їх.

Перша — CVE-2026-123710 з оцінкою CVSS 9.8 — дозволяє неавтентифікованому зловмиснику перехопити підписування токенів реєстру: фактично отримати «головний ключ», яким підписані всі дозволи на читання й запис. Друга — CVE-2026-110697 з CVSS 9.9 — дозволяє користувачеві, який може створити простір імен, викрадати токени робот-акаунтів інших орендарів.

Спільне в обох: після експлуатації зловмисник може читати приватні образи разом із секретами та обліковими даними, що збережені всередині них, а також перезаписувати образи — і підмінений образ розповсюджується на кожну систему, яка згодом його завантажить. По суті, це готовий сценарій атаки на ланцюг постачання програмного забезпечення.

Що таке Red Hat Quay і чому ключі підпису — це все

Red Hat Quay — це приватний реєстр контейнерів, який зазвичай розгортають або як окремий сервіс (standalone, через Podman чи Docker), або через Quay Operator в OpenShift, або як дзеркальний реєстр (mirror registry) для OpenShift. Багато команд зберігають у ньому закриті образи застосунків, і саме реєстр вирішує, хто може завантажувати (pull) та викладати (push) образи.

Механізм авторизації в Quay побудований на токенах. Коли клієнт просить доступ, сервіс /v2/auth видає йому підписаний токен (JWT), який реєстр потім приймає для конкретного репозиторію. Підписує ці токени набір «службових ключів» (service keys), які Quay вважає довіреними. Хто володіє довіреним ключем — той може створювати власні токени на будь-який репозиторій.

Саме цей механізм і зламали. Ключова деталь: коли Quay ротує ключі через ендпоінт /keys, він перевіряє, що запит підписаний уже довіреним ключем із правильними audience та issuer. Але він не перевіряє, чи цей токен взагалі був виданий саме для ротації ключів. Анонімний токен, який будь-хто може безкоштовно отримати на /v2/auth, проходить цю перевірку — адже він підписаний довіреним ключем, а audience абонент обирає сам.

Технічні деталі атаки

Атака складається з кількох простих кроків. Спочатку зловмисник отримує анонімний токен реєстру на /v2/auth. Далі передає цей токен на ендпоінт ротації ключів /keys — і встановлює власний підписувальний ключ, якому Quay автоматично присвоює статус довіреного. Ключ можна створити без терміну дії: він «житиме» вічно.

Наслідки для власника реєстру катастрофічні:

• Зловмисник може завантажувати (pull) приватні образи будь-якого репозиторію — включно з образами інших організацій — разом із секретами, API-ключами чи обліковими даними, які розробники помилково «зашили» всередину.
• Може викладати (push) або перезаписувати образи. Підмінений образ поширюється на кожну систему, яка пізніше його завантажить, — а це класичний вектор атаки на ланцюг постачання.
• Зберігає доступ назавжди: встановлений ключ не має терміну дії та переживає перезапуски реєстру, поки його хтось не видалить вручну.
• Може видаляти легітимні ключі працюючого реєстру — після чого звичайні push/pull починають падати з помилками «authentication required» або «unauthorized», навіть якщо з обліковими даними користувачів усе гаразд.

Red Hat окремо наголошує на двох підступних моментах. По-перше, анонімний доступ у Quay увімкнений за замовчуванням (параметр FEATURE_ANONYMOUS_ACCESS=True у Quay 3.18.2) — тобто зловмиснику не потрібен навіть обліковий запис. По-друге, вимкнення анонімного доступу не рятує: будь-який дійсний обліковий запис Quay усе одно може експлуатувати ваду. Скидання паролів і перегенерація токенів роботів теж не відкликають встановлений шкідливий ключ.

Логіка цієї вразливості, за даними Bugzilla Red Hat, присутня в Quay ще з першого публічного коміту — тобто це не свіжа помилка, а давній недолік, який лише тепер виявили.

Друга критична вразливість: CVE-2026-110697

Одночасно Red Hat розкрила ще одну критичну ваду — CVE-2026-110697 з оцінкою CVSS 9.9. Вона стосується багатоорендарних розгортань Quay і дозволяє користувачеві, який може створити простір імен (namespace), викрадати токени робот-акаунтів інших орендарів.

Технічна причина — класична помилка з оператором SQL LIKE. Код, що виводить список робот-акаунтів, будує шаблон LIKE з назви простору імен, не екрануючи спеціальні символи. У SQL LIKE символ підкреслення (_) збігається з будь-яким одним символом. Тож простір імен із підкресленням у потрібній позиції може «збігтися» з простором імен іншого орендаря — і повернути його робот-акаунти разом із розшифрованими токенами.

Атакуючому не потрібні підвищені привілеї, а жертві не треба робити жодних дій. Побічний ефект: видалення простору імен атакуючого призводить до видалення відповідних робот-акаунтів, що може «обрізати» системи, які на них покладаються. Red Hat окремо зазначає: там, де Quay є інтегрованим реєстром OpenShift, викрадені облікові дані роботів можна використати для впровадження шкідливих образів у CI/CD-конвеєри.

Хто під загрозою

Обидві вразливості зачіпають, за даними Red Hat, кожну версію Quay 3 і Quay 5. У документації компанії серед уразливих конфігурацій названо:

• standalone-розгортання Quay (Podman або Docker);
• Quay, розгорнутий через Quay Operator в OpenShift;
• mirror registry для Red Hat OpenShift.

Причому вразливими є не лише публічні, а й внутрішні реєстри: будь-який екземпляр Quay, до якого можуть дістатися недовірені клієнти, — включно з тими, що «заховані» всередині мережі. Це важливо: команди часто вважають внутрішній реєстр безпечним за замовчуванням, а саме він тут і є головною ціллю.

Хостинг Quay.io (керований сервіс Red Hat) компанія вже виправила. Але self-hosted інсталяції потребують ручного оновлення. Виправлені збірки Red Hat випустила для восьми гілок Quay 3: 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 і 3.18.3. Для тих, хто збирає Quay із вихідного коду (Project Quay), фікс міститься в коміті 094cfb024f01 — але найновіший тег v3.18.2 цього фіксу ще не містить, тож «просто взяти останній реліз» недостатньо.

Обидві вади виявив дослідник Red Hat Дейв О'Коннор (Dave O'Connor). Хронологія показова: перший баг (CVE-2026-110697, ін'єкція через LIKE) Red Hat зафіксувала 14 жовтня 2026 року, другий (CVE-2026-123710, неавтентифікована ротація ключів) — 6 листопада, а 11 листопада обидва CVE-записи було опубліковано, а виправлення злито в репозиторій. Тобто від першого звіту до фіксу минуло 28 днів.

Як захиститися: кроки Red Hat

Red Hat пропонує чотири кроки — і їх варто виконати в правильному порядку, тому що до встановлення виправлення жоден із перших трьох не дає стійкого захисту:

1. Заблокуйте ендпоінт /keys на рівні проксі або балансувальника навантаження — доступ до нього мають отримувати лише довірені внутрішні компоненти.
2. Перегляньте журнали аудиту на наявність подій service_key_rotate та service_key_delete, де поле expiration_date порожнє (null). Це індикатор встановленого шкідливого ключа.
3. Видаліть усі затверджені службові ключі, які ви не впізнаєте.
4. Встановіть виправлену збірку для своєї гілки.

Чому порядок важливий: доки виправлення не розгорнуто, зловмисник може додати новий ключ тим самим способом — тож видалення шкідливого ключа без оновлення дає лише тимчасовий ефект. Red Hat підкреслює: «вимкнення анонімного доступу вас не захищає», а встановлений шкідливий ключ продовжує працювати після скидання паролів і зміни токенів роботів.

Чому це урок для всіх, хто працює з контейнерами

Цей інцидент — не лише про Red Hat. Він про те, що реєстр контейнерів є критичним вузлом ланцюга постачання програмного забезпечення, і компрометація цього вузла дає зловмиснику набагато більше, ніж злам одного застосунку: він отримує точку, з якої можна поширити шкідливий код на всі системи, що тягнуть образи.

Кілька практичних висновків для команд DevOps та безпеки. Перше — не тримайте секрети всередині образів; використовуйте зовнішні сховища секретів, адже саме «зашиті» облікові дані роблять витік образів особливо болючим. Друге — ставтеся до внутрішнього реєстру як до потенційно доступного зловмиснику ресурсу: обмежуйте мережевий доступ і стежте за логами. Третє — регулярно звіряйте інвентар контейнерних образів із джерелами та перевіряйте, чи немає у ваших системах відомих витоків облікових даних — зокрема через наш інструмент перевірки витоків.

Висновок

Дві критичні вразливості в Red Hat Quay — нагадування про те, що навіть у зрілих інфраструктурних продуктах роками можуть жити вади, які повністю ламають модель безпеки. Особливо показовою є CVE-2026-123710: помилка в перевірці одного типу токена перетворює анонімного відвідувача на власника «головного ключа» всього реєстру.

Якщо ваша команда розгортає self-hosted Red Hat Quay (або Project Quay), не відкладайте: перевірте версію, виконайте чотири кроки від Red Hat і оновіться до виправленої збірки. А щоб розуміти, як захищати контейнерні середовища та ланцюги постачання системно, варто підвищувати кваліфікацію — наприклад, через курси з кібербезпеки чи спеціалізовані галузеві події, де ці теми розбирають практики.