Quay signiert die Zugriffstoken für Push- und Pull-Vorgänge mit Schlüsseln, denen es vertraut. Über die Lücke kann ein Angreifer einen eigenen Schlüssel ohne Ablaufdatum in diese Liste eintragen. Anschließend akzeptiert Quay damit signierte Token für jedes Repository. So lassen sich private Images abrufen, mitsamt den darin gespeicherten Geheimnissen und Zugangsdaten. Angreifer können Images außerdem hochladen oder überschreiben. Die Änderung erreicht dann jedes System, das diese Images später zieht.
Der eingeschleuste Schlüssel übersteht Neustarts, bis ihn jemand entfernt. Mit ihm lassen sich auch die Schlüssel der laufenden Quay-Instanzen löschen. Danach schlagen normale Push- und Pull-Vorgänge mit Authentifizierungsfehlern fehl.
Ursache ist eine unvollständige Prüfung im Schlüsselserver von Quay. Bei einer Anfrage zum Ersetzen eines Schlüssels prüft er zwar, ob das Token von einem vertrauenswürdigen Schlüssel signiert ist und die erwartete Zielgruppe (Audience) und den erwarteten Aussteller trägt. Ob das Token überhaupt für die Schlüsselrotation ausgestellt wurde, prüft er jedoch nicht. Deshalb reicht ein anonymes Token vom Endpunkt /v2/auth: Quay signiert es mit einem vertrauenswürdigen Schlüssel, und die Zielgruppe legt der Aufrufer selbst fest. Laut Bugreport steckt diese Logik seit dem ersten öffentlichen Commit in Quay.
Gleichzeitig wurde eine zweite kritische Lücke offengelegt: CVE-2026-110697 (CVSS 9.9). Ein Quay-Nutzer, der einen Namespace anlegen darf, kann damit die Tokens von Robot-Accounts anderer Mandanten stehlen und deren Images lesen, hochladen oder überschreiben. Der Fehler sitzt im Code, der Robot-Accounts auflistet. Er baut aus dem Namespace-Namen ein SQL-LIKE-Muster, ohne Platzhalterzeichen zu maskieren. In SQL LIKE steht ein Unterstrich für ein beliebiges einzelnes Zeichen. Ein Namespace mit einem Unterstrich an der passenden Stelle trifft deshalb den Namespace eines anderen Mandanten und liefert dessen Robot-Accounts samt entschlüsselten Tokens. Erhöhte Rechte braucht der Angreifer nicht, das Opfer muss nichts tun. Wird der Namespace des Angreifers gelöscht, verschwinden auch die zugehörigen Robot-Accounts. Das kann Systeme abschneiden, die auf sie angewiesen sind. Dient Quay als integrierte Registry für OpenShift, lassen sich mit gestohlenen Robot-Zugangsdaten nach Angaben von Red Hat bösartige Images in CI/CD-Pipelines einschleusen.
Entdeckt hat beide Lücken Dave O’Connor von Red Hat. Der Hersteller führt alle Versionen von Quay 3 und Quay 5 als von beiden Lücken betroffen. Bei CVE-2026-123710 nennt er Standalone-Installationen, per Quay Operator auf OpenShift bereitgestelltes Quay und die Mirror-Registry für Red Hat OpenShift. Gefährdet ist jede Quay-Instanz, die nicht vertrauenswürdige Clients erreichen können, auch interne Registries. Der CVE-Eintrag zu CVE-2026-123710 zeigte heute noch alle Quay-Pakete als betroffen und ohne Fix an, obwohl jeder Sicherheitshinweis die Lücke aufführt.
Red Hat empfiehlt zu CVE-2026-123710 folgende Schritte:
- den Endpunkt /keys am Proxy oder Load Balancer für alles außer vertrauenswürdigen internen Komponenten sperren
- die Audit-Logs nach Ereignissen vom Typ service_key_rotate und service_key_delete durchsuchen, bei denen expiration_date null ist
- unbekannte genehmigte Service-Schlüssel entfernen
- die korrigierte Version installieren, denn bis dahin kann ein Angreifer auf demselben Weg einen neuen Schlüssel einschleusen
„Das Abschalten des anonymen Zugriffs schützt Sie nicht“, schreibt Red Hat in seinem Artikel zur Behebung. Ein eingeschleuster Schlüssel funktioniert auch nach dem Zurücksetzen von Passwörtern und dem Ändern von Robot-Tokens weiter.
Auf der CVE-Seite zu CVE-2026-110697 nennt Red Hat dieselben acht Versionen als korrigiert und bezeichnet das Update als einzige vollständige Abhilfe. Quay.io ist demnach bereits abgesichert. Keiner der acht Sicherheitshinweise führt diese CVE allerdings auf. Bis zum Update rät der Hersteller, das Anlegen von Organisationen oder Namespaces mit Unterstrich einzuschränken. Außerdem sollen Robot-Tokens für alle Namespaces rotiert werden, auf die ein Namespace mit Unterstrich passt, und Pulls oder Pushes beobachtet werden, die nicht zur üblichen Nutzung der Robot-Accounts passen. Das senkt das Risiko, die Lücke bleibt aber bestehen.
Der Upstream-Fix ergänzt die fehlende Prüfung auf Rotation. Er schreibt für Schlüssel, die über den Schlüsselserver hinzugefügt werden, ein Ablaufdatum vor und verhindert, dass Aufrufer die Zielgruppe eines Tokens wählen. Dieselbe Änderung behebt auch die Suche nach Robot-Accounts.