Red Hat Quay CVE-2026-123710 : la signature des jetons détournée

En bref. La vulnérabilité CVE-2026-123710 (CVE, Common Vulnerabilities and Exposures, est l'identifiant public d'une vulnérabilité), notée 9.8 sur 10 au barème CVSS (Common Vulnerability Scoring System, le barème de gravité des vulnérabilités), touche Red Hat Quay, un registre d'images de conteneurs. Elle permet à un client non authentifié d'installer sa propre clé de signature de jetons, approuvée et sans expiration. Avec cette clé, il fabrique des jetons acceptés pour n'importe quel dépôt du registre : lecture des images privées, écriture et remplacement de tags. Red Hat demande de restreindre l'accès au point de terminaison /keys et de rechercher les clés inconnues dans les journaux d'audit.

Ce qui s'est passé

Red Hat a publié l'avis CVE-2026-123710, relayé par SecurityWeek le 12 novembre 2026. La faille a été découverte par Dave O'Connor, de Red Hat. Selon SecurityWeek, ni l'avis ni le rapport Bugzilla n'indiquaient de version corrigée au 12 novembre. Selon SecurityWeek, des correctifs pour cette faille et pour une autre faille de Quay, CVE-2026-110697, ont été fusionnés le 11 novembre dans le dépôt GitHub du projet. Ils figurent dans la pull request #8056, intitulée « Fix CVE-2026-110697 and CVE-2026-123710 », reportée le 11 novembre sur la branche redhat-5.0 par la pull request #8057.

Le score CVSS attribué par Red Hat est 9.8, avec le vecteur AV:N/AC:L/PR:N/UI:N : attaque par le réseau, faible complexité, sans privilège ni action de l'utilisateur. Red Hat précise que ce score est préliminaire.

Comment fonctionne la faille

Quay signe avec des clés de service les jetons qui autorisent les opérations push et pull. Le serveur de clés de Quay gère ces clés, dont leur rotation.

Selon l'avis de Red Hat, la rotation authentifie l'appelant en vérifiant seulement que son jeton est signé par une clé déjà approuvée, avec l'audience et l'émetteur attendus. Elle ne vérifie pas que ce jeton est bien un jeton de rotation. Or un jeton anonyme délivré par le registre lui-même, obtenu avec des paramètres choisis par le client, remplit ces conditions. Red Hat classe le défaut en CWE-1287 (CWE, Common Weakness Enumeration, est le catalogue des types de faiblesses) : une validation incorrecte du type d'une entrée.

Les conséquences listées par Red Hat :

• Lecture de tout le registre. Les images privées d'autres utilisateurs et organisations, avec les secrets ou identifiants qu'elles contiennent.
• Écriture. Le remplacement d'images, qui touche tous les systèmes qui les téléchargent ensuite.
• Persistance. La clé installée peut ne jamais expirer et survit aux redémarrages tant qu'on ne la retire pas.
• Déni de service. L'attaquant peut supprimer les clés qu'utilisent les instances Quay en fonctionnement ; le rapport Bugzilla de Red Hat, cité par SecurityWeek, précise que la rotation supprime au passage la clé légitime de l'instance. Les clients reçoivent alors des erreurs d'authentification alors que leurs identifiants n'ont pas changé.

Deux précisions de Red Hat changent la façon de réagir. Désactiver l'accès anonyme ne protège pas, car tout compte Quay valide peut exploiter la faille. Et réinitialiser les mots de passe ou régénérer les jetons des comptes robots ne révoque pas une clé de signature illégitime.

Qui est concerné

Red Hat cite trois environnements :

• Red Hat Quay autonome, déployé avec Podman ou Docker ;
• Red Hat Quay déployé par le Quay Operator sur OpenShift ;
• le mirror registry pour Red Hat OpenShift.

Est exposée toute instance Quay que des clients non fiables peuvent atteindre, y compris un registre interne. Red Hat rappelle que l'accès anonyme est activé par défaut.

En pratique, un registre interne joignable depuis l'ensemble du réseau de l'entreprise, ou depuis des agents d'exécution d'intégration continue (CI) partagés, entre dans ce périmètre.

Les mesures à prendre maintenant

Les trois premières mesures viennent de l'avis de Red Hat.

1. Restreindre /keys. Au niveau du proxy ou de l'équilibreur de charge, n'autorisez l'accès au point de terminaison /keys qu'aux composants internes de confiance. Selon l'avis, seules les instances dont /keys est joignable par des clients non fiables sont affectées : c'est donc la mesure prioritaire en attendant le correctif.

2. Chercher les traces dans les journaux d'audit. Red Hat demande de rechercher les événements service_key_rotate et service_key_delete dont la date d'expiration (expiration_date) est nulle.

3. Supprimer les clés approuvées inconnues. Red Hat prévient que cette suppression n'est pas durable avant le déploiement d'un build corrigé, puisque la même requête anonyme peut réinstaller une clé. Conséquence : restreindre d'abord, nettoyer ensuite.

4. Suivre la publication d'une version corrigée dans l'avis Red Hat et dans les notes de version de Quay, puis planifier la mise à jour.

Si des clés illégitimes ont été trouvées

L'avis ne décrit pas de procédure d'investigation. Les étapes suivantes sont des bonnes pratiques de réponse à incident adaptées à un registre.

• Fixer la fenêtre d'exposition : de la première rotation suspecte à la suppression de la clé.
• Considérer les images privées comme lues. Inventoriez les secrets embarqués dans les images (fichiers de configuration, variables d'environnement définies au build, clés) et faites-les tourner.
• Contrôler l'intégrité des images. Comparez les condensats (digests) des tags en production avec ceux produits par vos pipelines de build, à partir des journaux de CI. Un tag dont le condensat ne correspond à aucun build connu doit être traité comme remplacé.
• Retrouver les consommateurs. Les clusters, les agents d'exécution et les postes qui ont tiré une image pendant la fenêtre sont à examiner.

Réduire l'impact d'une prochaine faille de registre

Ces mesures sont des bonnes pratiques DevSecOps ; elles ne viennent pas de l'avis.

Ne pas faire confiance au registre seul. Signez les images dans le pipeline et vérifiez la signature au déploiement, par exemple avec Sigstore et une politique d'admission dans le cluster. Une image remplacée dans le registre échoue alors à la vérification, à condition que la politique d'admission l'exige et que la clé de signature des images ne soit pas stockée dans le registre ni dans les images.

Déployer par condensat. Référencer une image par son condensat plutôt que par son tag empêche qu'un tag réécrit change silencieusement ce qui tourne en production.

Sortir les secrets des images. Une image ne devrait contenir aucun identifiant. Injectez-les à l'exécution depuis un gestionnaire de secrets. La lecture d'une image privée devient alors une fuite de code, pas une fuite d'accès.

Limiter qui joint le registre. Un registre interne n'a pas besoin d'être joignable depuis tout le réseau. Restreignez les points de terminaison d'administration aux réseaux d'administration.

Comment vérifier

• Une requête vers /keys depuis un poste ou un agent d'exécution non autorisé est refusée au niveau du proxy.
• La recherche dans les journaux d'audit des événements service_key_rotate et service_key_delete sans date d'expiration est faite et documentée.
• La liste des clés de service approuvées ne contient que des clés identifiées.
• Les condensats des images en production correspondent à des builds connus.

FAQ

Qu'est-ce que CVE-2026-123710 ?

Une vulnérabilité critique (CVSS 9.8 selon Red Hat) du serveur de clés de Red Hat Quay. Un client non authentifié peut y installer une clé de signature approuvée et sans expiration, puis fabriquer des jetons valables pour tous les dépôts.

Désactiver l'accès anonyme suffit-il ?

Non. Red Hat précise que tout compte Quay valide peut exploiter la faille. La mesure efficace est de restreindre l'accès à /keys aux composants internes de confiance.

Existe-t-il un correctif ?

Des correctifs ont été fusionnés dans le dépôt GitHub de Quay le 11 novembre 2026. Selon SecurityWeek, l'avis de Red Hat n'identifiait pas encore de version corrigée le 12 novembre : suivez l'avis pour la version à déployer.

Le mirror registry d'OpenShift est-il touché ?

Oui, Red Hat le cite parmi les environnements concernés, avec Quay autonome et Quay déployé par l'Operator sur OpenShift.

Sources

• Red Hat, avis CVE-2026-123710 : https://access.redhat.com/security/cve/cve-2026-123710
• Red Hat, article de solution 7149923 : https://access.redhat.com/solutions/7149923
• Quay, pull request #8057 (report des correctifs sur redhat-5.0) : https://github.com/quay/quay/pull/8057
• SecurityWeek, Critical Red Hat Quay Vulnerability Could Expose Private Container Images, 12 novembre 2026 : https://www.securityweek.com/critical-red-hat-quay-vulnerability-could-expose-private-container-images/

---

Pour revoir la chaîne de confiance de vos images, du build au déploiement, WeeSec accompagne les équipes en DevSecOps.