Red Hat Quay is getroffen door twee kritieke kwetsbaarheden die aanvallers in staat stellen om containerimages te lezen en te wijzigen in (private) repositories. Daarmee kan niet alleen vertrouwelijke inhoud worden blootgelegd, maar kunnen updates zich ook door het hele ecosysteem verspreiden zodra systemen later images ophalen. Dit is precies het soort incident dat direct impact heeft op supply chain security.
In dit artikel zetten we de risico’s, de getroffen scenario’s en de aanbevolen acties op een rij, zodat je sneller kunt bepalen wat je vandaag nog moet doen.
Wat is er mis in Red Hat Quay?
De hoofdkwetsbaarheid, CVE-2026-123710 (CVSS 9.8), richt zich op sleutelbeheer dat Quay gebruikt voor het tekenen van tokens voor het pushen en pullen van images. Wie toegang heeft tot een Quay-registry (niet per se als geauthenticeerde gebruiker), kan misbruik maken van hoe Quay vertrouwensrelaties met sleutels afhandelt.
Het kernprobleem is dat een aanvaller een eigen sleutel kan toevoegen aan de sleutels die Quay vertrouwt. Vervolgens accepteert Quay tokens die met die sleutel zijn ondertekend. Daardoor kan de aanvaller tokens verkrijgen die toegang geven tot elke repository binnen het domein dat door Quay wordt bediend.
Wat kan een aanvaller precies doen met private images?
Met de hiervoor beschreven tokens kan een aanvaller:
- Private containerimages ophalen, waardoor geheimen of credentials die in die images zijn opgeslagen aan het licht komen.
- Images pushen of overschrijven. Hierdoor kunnen later omgevingen die dezelfde images ophalen, onbedoeld gewijzigde of schadelijke content ontvangen.
- Wijzigingen laten doorwerken naar systemen die later pullen. Dat maakt de impact breder dan alleen de registry zelf.
Daarnaast blijft de geplante sleutel actief tot iemand die verwijdert. Er wordt ook beschreven dat de aanvaller zelfs sleutelgerelateerde operaties kan saboteren, waardoor normale pushes en pulls vastlopen met authenticatiefouten.
Waarom is “anonymous access uit” niet genoeg?
Red Hat benadrukt dat het uitzetten van anonieme toegang geen afdoende bescherming biedt. Zelfs wanneer anonieme toegang uit staat, kan een aanvaller met een geldig account nog steeds misbruik maken van de kwetsbaarheid.
De achterliggende reden zit in de manier waarop Quay tokens ondertekent en valideert: een token kan door de key server worden geaccepteerd als de token klopt op basis van onder meer issuer en audience, zonder dat er wordt gecontroleerd of de token daadwerkelijk is bedoeld voor key-rotatie. Dit opent de deur voor aanvallen die tokencontrole omzeilen.
Tweede kritieke issue: robotaccounttokens van andere tenants
Naast CVE-2026-123710 is er tegelijk een tweede kwetsbaarheid bekendgemaakt: CVE-2026-110697 (CVSS 9.9). Deze fout betreft het mechanisme dat robotaccounts opsomt binnen Quay, waarbij de code een patroon voor SQL LIKE maakt op basis van een namespace. Daarbij worden wildcard-tekens niet goed afgeschermd.
Gevolg: een namespace met een underscore op de juiste positie kan matchen met een namespace van een andere tenant. Daardoor kunnen robotaccounttokens van die andere tenant worden teruggegeven—in gedecrypte vorm. De melder geeft aan dat de aanvaller geen verhoogde privileges nodig heeft en het slachtoffer geen handeling hoeft te verrichten.
Praktisch risico: wie deze robotcredentials bemachtigt, kan vervolgens lezen, pushen of overschrijven binnen de images van de andere tenant. Bij een geïntegreerde Quay-oplossing voor OpenShift kan dat zelfs leiden tot het injecteren van schadelijke images in CI/CD-pijplijnen.
Voor welke Quay-versies en omgevingen geldt dit?
Volgens Red Hat zijn alle versies van Quay 3 en Quay 5 aangewezen als getroffen voor beide issues. In de adviezen worden daarnaast verschillende deployscenario’s genoemd, waaronder:
- Standalone installs
- Quay die draait via de Quay Operator op OpenShift
- De mirror registry van Red Hat OpenShift
Verder geldt het risico voor elk Quay-exemplaar dat onbetrouwbare clients kan bereiken, inclusief interne registries waarbij toegang niet strak genoeg is afgeschermd.
Directe acties die Red Hat aanbeveelt
Om de blootstelling te verlagen voordat je de fix volledig uitgerold hebt, geeft Red Hat concrete stappen. Begin bij voorkeur met blokkeren en het controleren van sleutels, en plan daarna het installeren van de aangepaste builds.
1) Beperk toegang tot het keys-eindpunt
Blockeer of beperk op een proxy of load balancer het endpoint /keys zodat alleen vertrouwde interne componenten er toegang toe hebben. Daarmee voorkom je dat externe partijen misbruik kunnen maken van sleutel-gerelateerde functionaliteit.
2) Controleer auditlogs op onverklaarbare key-rotaties
Doorzoek audit logs op events zoals service_key_rotate en service_key_delete, specifiek waar expiration_date op null staat. Dat kan duiden op sleutels zonder vervaldatum die niet horen in je normale beheerproces.
3) Verwijder ongekende approved service keys
Ga na welke approved service keys je omgeving bevat en verwijder sleutels die je niet herkent. Let op: Red Hat geeft aan dat het verwijderen van een geplante sleutel niet altijd het gewenste effect heeft als de fix nog niet is toegepast, omdat een aanvaller opnieuw kan toevoegen via dezelfde zwakte.
4) Installeer de fixed release
Red Hat heeft fixed builds uitgebracht voor acht Quay 3 branches. Installeer de aangepaste versie om de volledige logica achter de kwetsbaarheid te corrigeren. Totdat dit gebeurt, blijft de kern van het probleem bestaan.
Wat moet je doen zolang de fix nog niet live is?
Ook wanneer je al mitigerende maatregelen neemt, blijft de kwetsbaarheid in de beschrijving bestaan totdat de update draait. Daarom luidt het advies: combineer mitigation met een strak updateplan.
Voor CVE-2026-110697 noemt Red Hat bovendien extra voorlopige maatregelen. Zo kun je:
- Beperken wie organisaties of namespaces kan aanmaken die underscore bevatten.
- Robot tokens rotaten voor namespaces die overeenkomen met het patroon waarin underscore kan matchen.
- Letten op push- of pull-activiteiten die niet passen bij normaal robotaccountgebruik.
Deze maatregelen verlagen het risico, maar lossen het onderliggende probleem niet volledig op.
Hoe ziet de uiteindelijke fix eruit?
Volgens Red Hat bevat de upstream fix voor CVE-2026-123710 onder meer:
- Een ontbrekende controle op key-rotatie
- De eis dat sleutels die via de key server worden toegevoegd, een vervaldatum krijgen
- Het voorkomen dat callers de audience van tokens naar eigen hand kunnen zetten
Hetzelfde pakket aan wijzigingen zou ook de robotaccount-zoekfunctie corrigeren die verantwoordelijk is voor CVE-2026-110697.
Conclusie: pak Red Hat Quay nu aan
De combinatie van het kunnen lezen én overschrijven van private containerimages, plus het risico op diefstal van robotaccounttokens van andere tenants, maakt dit incident bijzonder urgent voor iedereen die Red Hat Quay gebruikt als containerregistry. Zeker omdat de gevolgen doorwerken naar systemen die later images ophalen.
Vervang niet alleen “afspraak” door actie: blokkeer eerst toegang waar dat kan, controleer auditlogs en verwijder ongekende sleutels, maar plan vooral het installeren van de fixed release. Daarmee verklein je de kans op datalekken en supply chain-manipulatie tot het niveau waar je weer veilig verder kunt bouwen en deployen.
Gerelateerde leessuggesties
Als je ook wilt kijken naar bredere risico’s rond containerregistries en kwaadaardige varianten in CI/CD, lees dan: Reverse shells via GitHub: 60.000 repositories. Voor context rond misbruik van infrastructuur en identity-verwarring kan ook helpen: Identity context voor SOC: sluit blind spots.
Bron: https://thehackernews.com/2026/11/critical-red-hat-quay-flaw-lets.html
