In der Container-Registry Red Hat Quay steckt eine Lücke, die kaum schlimmer ausfallen könnte: Ohne Benutzerkonto kann ein Angreifer der Registry einen eigenen Signaturschlüssel unterschieben und sich danach selbst Zugriffstoken für jedes Repository ausstellen. Red Hat hat die Schwachstelle CVE-2026-123710 am 11. November 2026 veröffentlicht, stuft sie als kritisch ein und bewertet sie mit einem CVSS-Wert von 9,8. Am selben Tag erschienen korrigierte Versionen für acht Versionszweige von Quay 3 – und eine zweite kritische Lücke, CVE-2026-110697, wurde bekannt.

Warum eine Registry ein lohnendes Ziel ist

Eine Container-Registry ist das Lager für Container-Images: Build-Systeme laden fertige Images dorthin hoch, Kubernetes- und OpenShift-Cluster holen sie von dort ab und starten sie. Quay ist die Registry-Software von Red Hat; sie läuft als gehosteter Dienst unter quay.io und als Red Hat Quay im eigenen Rechenzentrum, das quelloffene Gegenstück heißt Project Quay.

Private Images sind aus zwei Gründen heikel. Erstens enthalten sie oft mehr als Programmcode: In Schichten älterer Builds finden sich in der Praxis immer wieder Konfigurationsdateien, API-Schlüssel, Datenbank-Passwörter oder Zertifikate, die nie hätten eingebacken werden dürfen. Wer das Image lesen kann, liest sie mit. Zweitens vertrauen alle nachgelagerten Systeme der Registry. Kann jemand ein Image unter einem bestehenden Tag überschreiben, läuft beim nächsten Abruf fremder Code in der Produktion – ein klassischer Angriff auf die Lieferkette.

CVE-2026-123710: Schlüsseltausch ohne Anmeldung

Quay signiert die Token, mit denen Clients Images hoch- und herunterladen dürfen, mit sogenannten Dienstschlüsseln. Ein interner Schlüsselserver unter dem Pfad /keys erlaubt es, diese Schlüssel zu rotieren. Laut Red Hat prüft er dabei nur, ob das vorgelegte Token von einem bereits genehmigten Dienstschlüssel signiert ist und Aussteller und Zielangabe stimmen – nicht aber, ob das Token überhaupt zum Rotieren berechtigt.

Genau so ein Token bekommt jeder: Der Endpunkt /v2/auth stellt auch anonymen Besuchern ein signiertes Token aus, und die Zielangabe darin kann der Aufrufer selbst bestimmen. Damit lässt sich ein eigener Schlüssel einsetzen, der die Genehmigung des alten erbt und ohne Ablaufdatum gespeichert werden kann. Token, die mit diesem Schlüssel signiert sind, akzeptiert die Registry anschließend für jedes Repository – lesend und schreibend, private Repositorys fremder Organisationen eingeschlossen.

In einem begleitenden Artikel der Wissensdatenbank zählt Red Hat die Folgen auf: private Images samt darin gespeicherter Geheimnisse abrufen, Images überschreiben, den Zugriff über Neustarts hinweg behalten und den regulären Betrieb stören. Denn beim Rotieren wird der legitime Schlüssel der laufenden Instanz gelöscht; Clients erhalten dann Fehlermeldungen wie „authentication required“ oder „unauthorized“, obwohl ihre Zugangsdaten stimmen.

Zwei Hinweise aus diesem Artikel sind für die Abwehr entscheidend. Der anonyme Zugriff ist in Quay standardmäßig eingeschaltet, doch ihn abzuschalten hilft nicht: Dann genügt jedes gültige Quay-Konto. Und wer Passwörter ändert oder Robot-Token neu erzeugt, entzieht einem untergeschobenen Signaturschlüssel damit nicht das Vertrauen. Betroffen ist laut Red Hat jede Instanz, die für nicht vertrauenswürdige Clients erreichbar ist, ausdrücklich auch interne Registrys sowie die „Mirror registry for Red Hat OpenShift“. Im Fehlerbericht bei Red Hat heißt es, die fehlerhafte Logik sei seit dem ersten öffentlichen Commit des Projekts vorhanden.

Symbolbild: gestapelte weiße Kühlcontainer an einer Kaimauer im Hafen

Symbolbild: Frachtcontainer, die Namensgeber der Container-Technik. Foto: AgainErick / Wikimedia Commons, CC BY-SA 4.0

CVE-2026-110697: Robot-Token fremder Mandanten

Die zweite Lücke, ebenfalls am 11. November veröffentlicht, bewertet Red Hat mit 9,9 und damit noch etwas höher; sie setzt allerdings ein Konto voraus. Die Funktion, die Robot-Konten eines Namensraums auflistet, baut aus dem Namen ein SQL-Suchmuster, ohne Platzhalterzeichen zu entschärfen. Ein Unterstrich steht in SQL-LIKE-Ausdrücken für ein beliebiges Zeichen. Wer einen Namensraum wie ab_c anlegt, bekommt deshalb auch die Robot-Konten von abxc oder ab-c angezeigt – samt entschlüsselter Token. Mit ihnen lassen sich die Images des fremden Mandanten lesen, hochladen und überschreiben.

Robot-Konten sind die technischen Zugänge, mit denen Build-Pipelines und Cluster auf die Registry zugreifen. Red Hat weist darauf hin, dass gestohlene Robot-Zugangsdaten dazu taugen, manipulierte Images in CI/CD-Abläufe einzuschleusen. Gefährdet sind vor allem Installationen, die sich mehrere Teams oder Kunden teilen.

Betroffene und korrigierte Versionen

Als betroffen führt Red Hat bei beiden Lücken Red Hat Quay 3 und Red Hat Quay 5. Am 11. November 2026 hat der Hersteller acht Sicherheitsmeldungen mit der Einstufung „Critical“ herausgegeben (RHSA-2026:99019 sowie RHSA-2026:99021 bis 99027). Sie liefern diese Versionen aus:

  • 3.9.28
  • 3.10.28
  • 3.12.24
  • 3.14.10
  • 3.15.9
  • 3.16.7
  • 3.17.7
  • 3.18.3

Die Dokumentation ist dabei nicht ganz stimmig, und das solltest du wissen: Die acht Meldungen nennen CVE-2026-123710 in ihrer CVE-Liste, CVE-2026-110697 aber nicht. Umgekehrt nennt die CVE-Seite zu CVE-2026-110697 genau diese acht Versionen als Korrektur, während die CVE-Seite zu CVE-2026-123710 am Vormittag des 12. November noch keine korrigierte Version auswies. Nach Lage der Dinge beheben die acht Versionen beide Lücken – im öffentlichen Quellcode von Project Quay wurden beide am 11. November in einer gemeinsamen Änderung korrigiert. Für Red Hat Quay 5 war am 12. November noch keine Sicherheitsmeldung zu finden, und Project Quay hatte auf GitHub noch keine neue Version markiert; die jüngste war dort 3.18.2.

Zum gehosteten Dienst schreibt Red Hat bei CVE-2026-110697, quay.io sei bereits korrigiert. Zu CVE-2026-123710 äußert sich der Hersteller in dieser Hinsicht nicht.

Ob eine der Lücken bereits ausgenutzt wurde, lässt Red Hat offen; die Einträge äußern sich dazu nicht. Gefunden hat beide ein Red-Hat-Mitarbeiter. Im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA (Stand 10. November 2026) steht keine der beiden.

Was du jetzt tun solltest

Stelle zuerst fest, welche Version läuft. Sie steht im Tag des Quay-Images: Bei einer Installation mit Podman zeigt ihn die Containerliste, unter OpenShift verrät die Version des Quay-Operators den Stand.

podman ps --format "{{.Names}}  {{.Image}}"
oc get csv -A | grep -i quay

Danach in dieser Reihenfolge:

  1. Aktualisieren. Spiele die korrigierte Version deines Versionszweigs ein. Für CVE-2026-110697 gibt es laut Red Hat keinen anderen vollständigen Schutz, und bei CVE-2026-123710 hält das Aufräumen erst mit einer korrigierten Version.
  2. Bis dahin /keys abschirmen. Red Hat empfiehlt, den Pfad /keys am Proxy oder Load Balancer so zu sperren, dass nur vertrauenswürdige interne Komponenten ihn erreichen. Für die zweite Lücke rät der Hersteller, das Anlegen von Organisationen und Namensräumen mit Unterstrich einzuschränken.
  3. Protokolle sichten. Suche in den Audit-Logs nach den Ereignissen service_key_rotate und service_key_delete, bei denen das Feld expiration_date leer ist. Die Logs und die Liste der Dienstschlüssel sind Superusern vorbehalten; in der Programmierschnittstelle von Quay liegen sie unter /api/v1/superuser/logs und /api/v1/superuser/keys. Achte außerdem auf Pulls und Pushes von Robot-Konten, die nicht zum gewohnten Muster passen.
  4. Unbekannte Schlüssel entfernen – nach dem Update. Lösche genehmigte Dienstschlüssel, die du nicht zuordnen kannst. Red Hat warnt: Solange keine korrigierte Version läuft, kann ein Angreifer einfach einen neuen Schlüssel installieren.
  5. Geheimnisse rotieren. Erzeuge die Robot-Token neu, zumindest für Namensräume, deren Name mit einem Namensraum mit Unterstrich kollidieren kann. Findest du Spuren eines fremden Schlüssels, gelten alle Zugangsdaten, die in privaten Images stecken, als offengelegt und müssen ersetzt werden; prüfe dann auch, ob Tags auf unerwartete Image-Digests zeigen.

Quellen

Bildnachweis