Une faille de 15 ans dans la sécurité SSH : que faire ?

Action requise : Mettez à jour OpenSSH vers la version 10.3p1 ou supérieure. Correctif disponible dès maintenant.

‍

Apr 29, 2026
Partager

QU'AVONS-NOUS DÉCOUVERT ?

Cyera Research a découvert une faille critique dans OpenSSH, le logiciel qui sécurise l'accès à distance à pratiquement tous les serveurs Linux dans le monde. Un certificat SSH forgé peut contourner les restrictions de principaux et accorder un accès en tant qu'utilisateur non autorisé, y compris root, sur les serveurs utilisant la configuration affectée. L'exploitation nécessite une seule connexion SSH, mais dépend de l'émission par l'autorité de certification (CA) d'un certificat dont le contenu principal est influencé par l'attaquant. La faille était présente depuis plus de 15 ans et a été corrigée cette semaine.

En termes simples : imaginez une porte qui vérifie votre identité avant de vous laisser entrer. Ce bug signifie que si vous insérez une virgule au milieu de votre nom sur votre badge — « Jean,Directeur » au lieu de « Jean » — la porte interprète cela comme deux identités, voit « Directeur » et vous laisse entrer avec les droits de directeur. C'est exactement ce que faisait OpenSSH.
OpenSSH possède deux portes. Seule l'une d'entre elles — le chemin cert-authority dans authorized_keys — interprète la virgule de cette manière. L'autre (TrustedUserCAKeys) ne le fait pas.
‍

CVE ET CHRONOLOGIE

QUI EST CONCERNÉ ?

Toute organisation dont les serveurs Linux utilisent l'authentification par certificat SSH avec une configuration spécifique : entrées cert-authority dans les fichiers authorized_keys. Cette configuration est courante dans :

  • Les hôtes bastions et les serveurs de rebond
  • Les pipelines CI/CD (GitHub Actions, GitLab CI, Jenkins)
  • Les environnements ayant adopté les certificats SSH de manière incrémentale — en les ajoutant aux fichiers authorized_keys existants plutôt qu'en migrant vers une configuration centralisée
  • Les organisations utilisant HashiCorp Vault, Netflix BLESS ou des flux de travail d'autorité de certification SSH personnalisés

‍

Si votre équipe utilise la configuration alternative — TrustedUserCAKeys dans sshd_config — vous n'êtes pas concerné.

‍

QUEL EST LE RISQUE ?

Un attaquant capable d'obtenir un certificat avec un nom de principal forgé contenant une virgule — même via un chemin d'émission à faible privilège — peut exploiter cette faille pour s'authentifier en tant que root sur les serveurs utilisant la configuration affectée, si l'autorité de certification ne rejette pas les principaux contenant des virgules.

  • Impact sur l'ensemble du parc : un certificat forgé peut être réutilisé sur tous les serveurs faisant confiance à cette autorité de certification via authorized_keys, lorsque les valeurs principals= correspondent à un fragment du principal forgé.
  • Exploitation déterministe : une fois le certificat forgé obtenu, l'attaque se résume à une simple connexion SSH : aucun code d'exploitation, aucune contrainte de temps, aucune attaque par force brute.
  • Invisible dans de nombreux journaux : le serveur considère l'authentification comme légitime ; aucun échec n'est consigné.
  • Exposition de données : l'accès root aux serveurs signifie l'accès aux bases de données, aux jetons d'API, aux identifiants cloud et aux secrets stockés sur ces hôtes.

‍

QUE DEVEZ-VOUS FAIRE ?

COMMENT CYERA PEUT-IL VOUS AIDER ?

L'authentification par certificat SSH est l'un des principaux vecteurs entre les identités et les données sensibles. La plateforme plateforme cartographie précisément quels actifs de données sont accessibles via les chemins d'accès par certificat SSH, afin que vous connaissiez votre périmètre d'exposition avant qu'un attaquant ne le découvre.

  • Cartographie des identités et des accès : Cyera identifie les magasins de données sensibles accessibles par des identités authentifiées via certificat SSH, y compris les agents CI/CD et automatisés.
  • Visibilité du rayon d'impact : lorsqu'une vulnérabilité telle que CVE-2026-35414 est divulguée, Cyera vous indique quels actifs de données sont exposés via les chemins SSH affectés
  • Requête de détection : Les clients Cyera peuvent exécuter la requête d'exposition d'identité SSH liée pour identifier les chemins d'accès des autorités de certification vers les données sensibles de leur environnement

‍

Pour une analyse technique approfondie — analyse des causes profondes, examen du code source, étapes d'exploitation, règles de détection et contestation du score CVSS — consultez le blog technique de Cyera Research

Partager