Wprowadzenie do problemu / definicja
Red Hat Quay to rejestr kontenerów wykorzystywany do przechowywania, dystrybucji oraz kontroli dostępu do obrazów używanych w środowiskach kontenerowych i procesach CI/CD. Ujawnione podatności pokazują, że naruszenie bezpieczeństwa takiego komponentu może bezpośrednio podważyć zaufanie do całego łańcucha dostaw oprogramowania.
W opisywanym przypadku chodzi o dwie krytyczne luki, które umożliwiają nieautoryzowany dostęp do prywatnych obrazów, ich modyfikację, a nawet trwałe zakłócenie działania mechanizmów autoryzacji. To problem szczególnie istotny dla organizacji korzystających z Quay jako centralnego repozytorium artefaktów wdrożeniowych.
W skrócie
Najgroźniejsza z podatności, oznaczona jako CVE-2026-123710, pozwala dodać własny klucz do listy zaufanych kluczy Quay. W praktyce otwiera to drogę do generowania tokenów akceptowanych przez rejestr dla dowolnych repozytoriów, co umożliwia odczyt oraz nadpisywanie prywatnych obrazów.
Druga luka, CVE-2026-110697, dotyczy błędu izolacji między tenantami. Użytkownik z możliwością tworzenia namespace’ów może przejąć tokeny kont robotycznych innych tenantów i użyć ich do pobierania lub publikowania obrazów. Obie podatności są szczególnie niebezpieczne w środowiskach współdzielonych oraz tam, gdzie rejestr zasila zautomatyzowane procesy buildów i wdrożeń.
Kontekst / historia
Red Hat Quay od lat pozostaje ważnym elementem ekosystemu kontenerowego, zwłaszcza w środowiskach enterprise oraz wdrożeniach powiązanych z OpenShift i praktykami DevSecOps. W takich architekturach rejestr obrazów nie jest wyłącznie magazynem danych, ale częścią zaufanej infrastruktury odpowiedzialnej za dostarczanie oprogramowania do kolejnych etapów cyklu życia aplikacji.
Znaczenie incydentu zwiększa fakt, że jedna z luk miała według opublikowanych informacji istnieć od pierwszego publicznego commita projektu. Taki scenariusz sugeruje długotrwały błąd projektowy w obszarze walidacji tokenów i operacji związanych z kluczami, co mogło wpływać na wiele wdrożeń przez długi czas przed wykryciem i przygotowaniem poprawek.
Analiza techniczna
CVE-2026-123710 dotyczy sposobu, w jaki Quay obsługuje klucze wykorzystywane do podpisywania tokenów autoryzacyjnych dla operacji push i pull. Problem polegał na tym, że komponent odpowiedzialny za podmianę kluczy akceptował token podpisany przez zaufany klucz i sprawdzał wybrane pola, takie jak issuer oraz audience, ale nie weryfikował, czy token został rzeczywiście wystawiony do operacji rotacji klucza.
W efekcie możliwe było użycie tokenu uzyskanego z endpointu autoryzacyjnego do operacji, której nie powinien obejmować. Atakujący mógł dodać własny klucz do zestawu zaufanych kluczy, a następnie podpisywać nim tokeny akceptowane przez rejestr dla dowolnych repozytoriów. Taki mechanizm prowadził do całkowitego obejścia kontroli dostępu na poziomie obrazów.
- odczyt prywatnych obrazów kontenerów,
- pozyskanie sekretów i poświadczeń zapisanych w warstwach obrazu,
- publikowanie złośliwych wersji obrazów,
- nadpisywanie istniejących artefaktów,
- usuwanie kluczy i wywoływanie problemów z autoryzacją.
Istotną cechą tej podatności jest także trwałość ataku. Dodany klucz pozostaje aktywny po restarcie usługi, dopóki nie zostanie ręcznie usunięty. Oznacza to, że samo ponowne uruchomienie instancji lub standardowa rotacja haseł nie rozwiązuje problemu.
Z kolei CVE-2026-110697 wynika z błędu w budowie wzorca SQL LIKE podczas wyszukiwania kont robotycznych. Nazwa namespace’u nie była prawidłowo oczyszczana z wildcardów, przez co znak podkreślenia mógł zostać wykorzystany do dopasowania przestrzeni nazw innego tenanta. W rezultacie system zwracał rekordy cudzych kont robotycznych wraz z odszyfrowanymi tokenami.
To przykład połączenia niewystarczającej walidacji danych wejściowych z nieprawidłową separacją danych między tenantami. W środowiskach wielodzierżawnych taka luka podważa podstawowe założenia izolacji organizacji i repozytoriów.
Konsekwencje / ryzyko
Ryzyko związane z obiema podatnościami należy uznać za krytyczne. W przypadku CVE-2026-123710 skutki obejmują naruszenie poufności, integralności i dostępności artefaktów kontenerowych. Atakujący może wykraść prywatne obrazy, osadzić złośliwy kod w legalnie używanych artefaktach i doprowadzić do ich dalszej propagacji w środowiskach downstream.
To bezpośrednie zagrożenie dla software supply chain. Jeśli organizacja automatycznie pobiera obrazy z Quay do buildów, testów lub produkcji, złośliwa modyfikacja może bardzo szybko rozprzestrzenić się na wiele systemów.
- wdrożenie backdoora do środowiska produkcyjnego,
- przejęcie sekretów uruchomieniowych,
- sabotaż procesów CI/CD,
- naruszenie integralności i zgodności release’ów,
- przestoje operacyjne wynikające z uszkodzenia autoryzacji.
CVE-2026-110697 zwiększa z kolei ekspozycję środowisk multi-tenant. Przejęcie tokenów kont robotycznych innych tenantów umożliwia działania podszywające się pod legalną automatyzację, co utrudnia wykrywanie i analizę incydentu. W praktyce oznacza to ryzyko cichego nadużycia zaufanych mechanizmów systemowych.
Rekomendacje
Organizacje korzystające z Red Hat Quay powinny potraktować sprawę priorytetowo i jak najszybciej wdrożyć poprawione wersje oprogramowania wskazane przez producenta. Aktualizacja pozostaje jedynym pełnym sposobem usunięcia obu podatności. W środowiskach zarządzanych przez operatorów lub zintegrowanych z OpenShift trzeba upewnić się, że aktualizacja obejmuje cały stos wdrożeniowy.
Do czasu zakończenia procesu aktualizacji warto ograniczyć dostęp do endpointu odpowiedzialnego za obsługę kluczy. Blokada na poziomie proxy, load balancera lub warstwy sieciowej może ograniczyć powierzchnię ataku, zwłaszcza dla podmiotów spoza zaufanej infrastruktury wewnętrznej.
- przeanalizować logi audytowe pod kątem operacji dodawania i usuwania kluczy,
- zweryfikować wszystkie zaufane klucze i usunąć nierozpoznane wpisy,
- sprawdzić anomalie w operacjach push i pull wykonywanych przez konta automatyczne,
- ograniczyć możliwość tworzenia namespace’ów do zaufanych użytkowników,
- przeprowadzić rotację tokenów kont robotycznych w razie podejrzenia nadużycia.
Dodatkowo warto wzmocnić odporność całego procesu dostarczania obrazów poprzez podpisywanie i weryfikację artefaktów, skanowanie obrazów pod kątem nieautoryzowanych zmian, egzekwowanie polityk admission control, segmentację dostępu do rejestru oraz monitoring zachowań kont serwisowych.
Podsumowanie
Ujawnione luki w Red Hat Quay pokazują, że rejestr kontenerów jest jednym z kluczowych punktów zaufania w nowoczesnych środowiskach chmurowych i kontenerowych. CVE-2026-123710 umożliwia przejęcie modelu zaufania przez dodanie własnego klucza podpisującego tokeny, natomiast CVE-2026-110697 narusza izolację tenantów przez błąd w logice dopasowania namespace’ów.
Z perspektywy obronnej najważniejsze są szybkie wdrożenie poprawek, przegląd kluczy i tokenów oraz dokładna analiza logów pod kątem oznak nadużycia. W organizacjach opierających procesy wdrożeniowe na Quay taki incydent należy traktować jako potencjalne naruszenie integralności całego łańcucha dostaw oprogramowania.
Źródła
- Critical Red Hat Quay Flaw Lets Attackers Read and Overwrite All Private Container Images in a Registry — https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
- Red Hat Bugzilla: CVE-2026-123710 — https://bugzilla.redhat.com/
- Red Hat Customer Portal: CVE-2026-123710 — https://access.redhat.com/
- Red Hat Customer Portal: CVE-2026-110697 — https://access.redhat.com/
- Upstream fix for Quay vulnerabilities — https://github.com/