Er is een Red Hat Quay kwetsbaarheid gemeld die direct raakt aan de veiligheid van container-images binnen enterprise registries. In het ergste scenario kunnen aanvallers niet alleen privébeelden bekijken, maar ook content in repositories vervangen door zelf-ondertekende updates. Dat maakt dit een serieus risico voor je software supply chain.
De fout staat geregistreerd als CVE-2026-123710 en heeft een CVSS-score van 9.8. Volgens Red Hat ontstaat het probleem wanneer de service die verantwoordelijk is voor signing keys toegankelijk is voor partijen die je niet vertrouwt.
Wat is Red Hat Quay en waarom is dit zo gevoelig?
Red Hat Quay is een container registry die containerimages opslaat, beheert en verspreidt. Organisaties gebruiken zo’n registry om te controleren wie images mag downloaden of uploaden. In moderne ontwikkel- en deploymentketens wordt die controle vaak gezien als een belangrijke beveiligingslaag: je wilt immers voorkomen dat kwaadwillenden “vertrouwde” artifacts kunnen injecteren.
Juist daarom is een lek in het onderteken- en token-mechanisme extra riskant. Als een aanvaller het tekenproces kan sturen, kan die de “vertrouwdheid” van images aantasten—zonder dat normale toegangsrestricties nog voldoende bescherming bieden.
De kern van de Red Hat Quay kwetsbaarheid: tekenkeys en registry-tokens
Red Hat meldt dat een service key server in Quay kan worden overgenomen. Daarbij gaat het om unauthenticated token signing: een aanvaller kan zonder account registry-tokens verkrijgen en vervolgens misbruik maken van zwakheden in het key-rotatieproces.
Het dreigingspad begint vooral wanneer anonymous access is ingeschakeld. In dat geval kan een aanvaller zonder geldige inlog alsnog een token krijgen. Vervolgens kan die een eigen signing key laten “vertrouwen” door het rotatiemechanisme te benutten.
Wat kan een aanvaller precies doen?
- Privé containerimages uitlezen, omdat tokens dan alsnog toegang kunnen geven.
- Read én write toegang krijgen tot in feite elke repository, waardoor normale toegangsregels worden omzeild.
- Images overschrijven, zodat andere systemen die later downloaden mogelijk niet de bedoelde artifacts binnenkrijgen.
Bovendien kan de kwaadaardige sleutel worden ingesteld zonder expiratiedatum. Die blijft volgens Red Hat ook na registry-herstarts bestaan, totdat iemand de ongeautoriseerde sleutel verwijdert.
Anonymous access is geen echte oplossing
Veel teams kijken bij dit soort meldingen eerst of anonymous access uitstaat. In dit geval waarschuwt Red Hat echter expliciet dat uitschakelen van anonymous access niet automatisch beschermt. Een aanvaller met een geldige Quay-account kan de fout nog steeds misbruiken.
Met andere woorden: je kunt het risico niet “afvangen” door alleen publieke toegang te beperken. De kwetsbaarheid zit in het sleutelbeheer en het signen van tokens.
Waarom “wachtwoorden wijzigen” niet genoeg is
Red Hat merkt ook op dat het wijzigen van wachtwoorden of het regenereren van robot tokens een deel van het probleem niet oplost. De reden: de aanval gaat uit van een ongeautoriseerde signing key die door het registry-systeem kan worden geaccepteerd.
Daarbij komt dat key-rotatie effecten heeft: Red Hat beschrijft dat rotatie de legitieme instance key kan verwijderen als bijwerking. Daarna kan een aanvaller vervolgens ook vervangende instance keys beïnvloeden of verwijderen, waardoor de registry in de war raakt.
Daarnaast: registries kunnen ook verstoring krijgen
Naast dat private images mogelijk worden blootgesteld en overschreven, kan de registry ook normale werking verliezen. Door de key-manipulatie kan uploaden of downloaden voor legitieme gebruikers worden gehinderd.
Dat maakt de gevolgen dubbel: je krijgt zowel een vertrouwelijkheids- en integriteitsrisico (lek/overwrite) als een beschikbaarheidsrisico (verstoring van de registry-processen).
Wat zegt Red Hat als aanpak?
Red Hat adviseert om het risico te beperken door de toegang tot de key-management service te beperken. Daarnaast stelt het bedrijf voor om logbestanden te controleren op verdachte wijzigingen aan keys.
Ook noemt Red Hat het belang van het verwijderen van ongeautoriseerde keys. Wel waarschuwt men dat aanvallers mogelijk opnieuw kwaadaardige keys kunnen installeren totdat er een fix is doorgevoerd.
Een belangrijke praktische conclusie: behandel dit niet als een incident dat je alleen “achteraf” oplost met wachtwoordherstel. Je moet je ook richten op het sleutelbestand zelf en op aanwijzingen in de logging.
Is er een fix beschikbaar?
In de publicatie staat dat zowel het advisory als de Bugzilla-rapportage geen vaste versie noemt. Tegelijk meldt Red Hat dat fixes voor deze kwetsbaarheid en een andere Quay-fout (CVE-2026-110697) op 11 november zijn samengevoegd in de GitHub-repository van het project.
Dat betekent voor organisaties: houd je release-cyclus en updateplanning strak in de gaten. Werk je Quay omgeving bij zodra jouw distributie of omgeving een bijpassende patch beschikbaar stelt, en combineer dat met het opschonen van eventuele ongeautoriseerde keys.
Gerelateerde incidenten: leer van eerdere supply-chain problemen
Deze melding past in een bredere trend waarin aanvallen niet alleen eindpunten treffen, maar ook de softwareketen. Als je meer wilt lezen over vergelijkbare risico’s bij het beschermen van build- en deploymentpijplijnen, bekijk dan ook:
- Software transparency: SBOM, AI BOMs en VEX uitgelegd
- GitHub CI secret stealer via gehackte accounts
- Reverse shells tegen Qlik Sense
Die onderwerpen helpen je om beter te kijken naar waar in je keten vertrouwen wordt opgebouwd—en waar dat vertrouwen kan worden misbruikt.
Checklist: wat je vandaag kunt doen
Als je Quay gebruikt in productie of kritieke pipelines, dan is tijd belangrijk. Dit zijn praktische stappen op hoofdlijnen:
- Beperk de toegang tot de key-management component (alleen waar dat strikt nodig is).
- Controleer logs op verdachte key-rotaties, key-vervangingen of ongebruikelijke token-acties.
- Zoek en verwijder ongeautoriseerde keys (niet alleen tokens of accountwachtwoorden).
- Plan zo snel mogelijk patching zodra de fix voor jouw omgeving beschikbaar is.
Door deze volgorde aan te houden, verklein je de kans dat aanvallers blijven profiteren van een sleutel die al is “geïnstalleerd” in het systeem.
Conclusie
De Red Hat Quay kwetsbaarheid (CVE-2026-123710) vormt een kritisch risico voor organisaties die hun containerimages via Quay beheren. De kern is dat een aanvaller token signing kan overnemen via misbruik van signing keys en rotatie, met als gevolg dat privéimages kunnen uitlekken en repositories kunnen worden overschreven.
Pak het daarom systematisch aan: herstel niet alleen accounts, maar focus ook op key-management, logcontrole en het opschonen van ongeautoriseerde keys. Combineer dat met een snelle update zodra de passende patch in jouw omgeving beschikbaar is.
