---
title: "Red Hat Quay: Kritische Lücke CVE-2026-123710 öffnet private Container-Images"
date: 2026-11-13T02:21:50+01:00
modified: 2026-11-13T02:21:50+01:00
category: sicherheit
type: news
author: Marcel Schönfelder
canonical: https://s-edv.com/news/red-hat-quay-cve-2026-123710-signaturschluessel-registry
keywords:
  - Red Hat
  - Quay
  - Container-Registry
  - CVE-2026-123710
  - OpenShift
  - Sicherheitslücke
  - Supply Chain
reading_time: 3
ai_notice: "Mit KI erstellt – redaktionelle Prüfung ausstehend"
---

# Red Hat Quay: Kritische Lücke CVE-2026-123710 öffnet private Container-Images

> Mit KI erstellt – redaktionelle Prüfung ausstehend ([KI-Transparenz](https://s-edv.com/ki-transparenz))

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 `/keys` am Reverse Proxy oder Load Balancer auf vertrauenswürdige interne Komponenten beschränken.
- Audit-Logs auf die Ereignisse `service_key_rotate` und `service_key_delete` mit leerem `expiration_date` prü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 `/keys` kann 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](https://s-edv.com/anleitungen/harbor-docker-container-registry)
- [Nginx als Reverse Proxy mit TLS manuell einrichten](https://s-edv.com/anleitungen/nginx-reverse-proxy-tls-einrichten)

## Quellen

- [Red Hat: CVE-2026-123710](https://access.redhat.com/security/cve/cve-2026-123710)
- [Red Hat: RHSA-2026:99019 für Quay 3.18.3](https://access.redhat.com/errata/RHSA-2026:99019)
- [Red Hat: Unbefugte Signaturschlüssel in Quay erkennen und entfernen](https://access.redhat.com/solutions/7149923)
- [Red Hat Bugzilla: Eintrag 2568072](https://bugzilla.redhat.com/show_bug.cgi?id=2568072)
- [SecurityWeek: Kritische Lücke in Red Hat Quay](https://www.securityweek.com/critical-red-hat-quay-vulnerability-could-expose-private-container-images/)