Red Hat Quay: Kritische Lücke CVE-2026-123710 öffnet private Container-Images
Red Hat warnt vor CVE-2026-123710 in der Container-Registry Quay, bewertet mit CVSS 9,8. Ein Angreifer kann ohne Konto einen eigenen Signaturschlüssel installieren und damit jedes Repository lesen und Images überschreiben. Red Hat hat am 11. November 2026 korrigierte Versionen für Quay 3.9 bis 3.18 veröffentlicht, für Quay 5 fehlt das Update noch.
Red Hat warnt vor einer kritischen Lücke in der Container-Registry Red Hat Quay. Über CVE-2026-123710 kann ein Angreifer ohne Anmeldung einen eigenen Signaturschlüssel in der Registry hinterlegen und sich damit Lese- und Schreibzugriff auf jedes Repository verschaffen, auch auf private Images. Red Hat bewertet die Lücke mit CVSS 3.1 9,8 und hat sie am 11. November 2026 veröffentlicht, zusammen mit Updates für Red Hat Quay 3.9 bis 3.18. Für Quay 5 steht ein Fix noch aus.
Betroffen sind laut Red Hat eigenständige Quay-Installationen mit Podman oder Docker, per Operator auf OpenShift betriebene Instanzen und die Mirror Registry für OpenShift, sofern nicht vertrauenswürdige Clients sie erreichen. Das schließt interne Registries ein. Betreiber sollten das Update noch heute einspielen.
Was ist passiert?
Quay signiert die Tokens, mit denen Clients Images ziehen und hochladen, mit Dienstschlüsseln. Beim Rotieren dieser Schlüssel prüft der Schlüsselserver laut Red Hat nur, ob das vorgelegte JWT von einem bereits freigegebenen Schlüssel stammt und Audience und Issuer passen, nicht aber, ob es überhaupt ein Rotations-Token ist. Ein anonymes Token vom Endpunkt /v2/auth besteht diese Prüfung. Der Angreifer kann so einen eigenen, freigegebenen Schlüssel ohne Ablaufdatum installieren. Registry-Tokens, die er damit signiert, akzeptiert Quay für jedes Repository, er kann Images lesen, überschreiben und Tags ersetzen.
Entdeckt hat die Lücke laut Red Hat Dave O'Connor aus dem eigenen Haus. Die Korrekturen sind am 11. November 2026 auch in das Upstream-Projekt Project Quay eingeflossen. Laut Bugzilla steckt der Fehler seit dem ersten öffentlichen Commit im Code.
Wer ist betroffen?
Entscheidend ist, ob der Endpunkt /keys von nicht vertrauenswürdigen Clients erreichbar ist. Anonymer Zugriff ist in Quay laut Red Hat standardmäßig eingeschaltet, dann braucht der Angreifer kein Konto. Das Abschalten hilft aber nicht, denn jedes gültige Quay-Konto reicht ebenfalls für den Angriff. Die Lücke steckt im Schlüsselserver von Quay.
Wie kritisch ist das?
Wer Images in einer Registry austauschen kann, kann Schadcode in jede Umgebung bringen, die diese Images zieht, vom Testsystem bis zum Produktionscluster. Red Hat weist zudem darauf hin, dass die Rotation den rechtmäßigen Instanzschlüssel löscht. Clients sehen dann Anmeldefehler, obwohl sich ihre Zugangsdaten nicht geändert haben. Hinweise auf Ausnutzung nennen die gelesenen Quellen nicht.
Was sollten Admins jetzt tun?
- Inventar: alle Quay-Instanzen erfassen, auch die Mirror Registry für OpenShift und interne Registries.
- Update: auf die korrigierten Versionen 3.9.28, 3.10.28, 3.12.24, 3.14.10, 3.15.9, 3.16.7, 3.17.7 oder 3.18.3 aktualisieren (RHSA-2026:99019 bis RHSA-2026:99027).
- Wo das nicht sofort geht und für Quay 5, Schutzmaßnahme von Red Hat: den Zugriff auf
/keysam Reverse Proxy oder Load Balancer auf vertrauenswürdige interne Komponenten beschränken. - Audit-Logs auf die Ereignisse
service_key_rotateundservice_key_deletemit leeremexpiration_dateprüfen und unbekannte freigegebene Dienstschlüssel entfernen. - Beachten: Das Löschen eines fremden Schlüssels hält laut Red Hat erst, wenn das korrigierte Build installiert ist, ohne Update oder Sperre von
/keyskann ein Angreifer sofort einen neuen setzen. Passwörter oder Robot-Tokens neu zu setzen, entfernt den fremden Schlüssel nicht. - Unerklärliche Anmeldefehler von Clients als möglichen Hinweis werten.
- Für Quay 5 und die Mirror Registry für OpenShift die CVE-Seite von Red Hat auf korrigierte Builds beobachten.
Einordnung für Unternehmen
Die eigentliche Lösung ist das Update, die Sperre von /keys überbrückt nur die Zeit bis dahin. Wer seine Registry intern betreibt, sollte sich nicht in Sicherheit wiegen, denn Red Hat zählt auch interne Registries zu den gefährdeten Installationen. Wurden Images in der Zwischenzeit verändert, reicht das nicht: Dann gehört die Herkunft der Images per Signatur oder Digest gegen bekannte Stände geprüft.
Passende Anleitungen auf S-EDV
- Harbor mit Docker installieren: CNCF-zertifizierte Container-Registry mit Trivy-Scanning und RBAC
- Nginx als Reverse Proxy mit TLS manuell einrichten
