OpenSSH 10.4 : vulnerabilites critiques corrigees et cryptographie post-quantique ML-DSA 44 — ce que les developpeurs open source doivent faire maintenant

Le 6 juillet 2026, l'equipe OpenSSH a publie la version 10.4, une mise a jour de securite majeure qui corrige trois vulnerabilites significatives et introduit le support experimental de la cryptographie post-quantique. Pour les developpeurs open source qui utilisent SSH des dizaines de fois par jour — git push, git pull, deploiements via rsync, connexions a des serveurs de production — cette mise a jour n'est pas optionnelle. Les trois failles corrigees sont toutes exploitables cote client, ce qui signifie qu'un serveur compromis ou malveillant peut les declencher lors d'une simple connexion SSH.

Ce bulletin arrive dans un contexte ou la securite de la supply chain logicielle est sous tension maximale. La tentative de backdoor xz-utils de 2024 avait deja revele la fragilite de l'ecosysteme OpenSSH. Deux ans plus tard, les vulnerabilites de la version 10.4 rappellent que meme sans backdoor intentionnelle, le code critique contient des failles qui peuvent etre exploitees par des attaquants sophistiques. Nous avions deja aborde les enjeux de securite des dependances dans notre guide sur l'audit de securite des dependances open source, et ce bulletin OpenSSH confirme l'urgence de maintenir une hygiene rigoureuse sur les outils fondamentaux de l'infrastructure developpeur.

Les trois vulnerabilites corrigees dans OpenSSH 10.4

Les notes de version d'OpenSSH 10.4, disponibles sur openssh.com/txt/release-10.4, detaillent trois correctifs de securite. Fait notable : les trois vulnerabilites affectent le cote client de la connexion SSH. Cela signifie que l'attaquant doit controler ou compromettre le serveur auquel le client se connecte pour exploiter ces failles. Dans le contexte actuel ou les attaques supply chain ciblent les infrastructures de developpement, ce vecteur est loin d'etre theorique.

1. Redirection de fichiers sftp via serveur malveillant

La premiere vulnerabilite concerne le client sftp. Un serveur malveillant pouvait manipuler les reponses du protocole SFTP pour rediriger les operations d'ecriture de fichiers vers des emplacements non prevus sur le systeme de fichiers du client. Concretement, lorsqu'un developpeur telecharge un fichier via sftp get fichier.tar.gz, le serveur malveillant pouvait faire en sorte que le fichier soit ecrit a un emplacement different de celui attendu — par exemple, ecraser un fichier de configuration critique comme ~/.bashrc ou ~/.ssh/authorized_keys. Cette technique permettrait a un attaquant d'obtenir un acces persistant au poste de travail du developpeur.

2. Path traversal dans scp

La deuxieme faille touche scp, le protocole de copie securisee. Un serveur malveillant pouvait exploiter un probleme de validation des chemins de fichiers pour ecrire des fichiers en dehors du repertoire cible specifie par l'utilisateur. Le path traversal classique — l'utilisation de sequences ../ dans les noms de fichiers — est une classe de vulnerabilites bien connue, mais sa presence dans scp est particulierement preoccupante car de nombreux scripts d'automatisation et pipelines CI/CD utilisent scp pour transferer des artefacts de build entre serveurs. Un serveur de build compromis pourrait ainsi injecter des fichiers malveillants dans l'arborescence du projet lors d'une copie qui semble anodine.

3. Use-after-free cote client ssh lors d'un changement de cle hote

La troisieme vulnerabilite est la plus technique et potentiellement la plus grave. Il s'agit d'un use-after-free dans le client ssh qui se declenche lorsqu'un serveur modifie sa cle hote en cours de session. Le use-after-free est une classe de vulnerabilites memoire ou un programme continue d'utiliser un bloc de memoire apres qu'il a ete libere. Cela peut mener a une execution de code arbitraire sur le poste client, car l'attaquant peut potentiellement placer des donnees controlees dans le bloc de memoire libere puis declencher son utilisation. Dans le cas d'OpenSSH 10.4, un serveur malveillant qui initie un changement de cle hote en milieu de session (une operation normalement legitime dans le protocole SSH) peut provoquer cette condition et potentiellement executer du code sur la machine du developpeur.

Les trois failles partagent un point commun essentiel : elles sont toutes exploitables cote client. Ce vecteur d'attaque est souvent sous-estime. On a tendance a penser que la menace SSH vient des attaques brute-force contre les serveurs, mais ici c'est l'inverse : c'est le developpeur qui se connecte a un serveur malveillant qui est la victime. Ce scenario est plausible dans de nombreux contextes : un serveur de build compromis dans un pipeline CI/CD, un serveur tiers d'un client ou partenaire, voire un depot Git heberge sur une infrastructure corrompue. La securisation de vos pipelines CI/CD est cruciale, comme nous l'avons detaille dans notre guide sur la securisation des pipelines CI/CD GitHub Actions.

Cryptographie post-quantique : ML-DSA 44 + Ed25519 dans OpenSSH

Au-dela des correctifs de securite, OpenSSH 10.4 introduit une fonctionnalite majeure pour l'avenir : le support experimental de signatures hybrides post-quantiques combinant ML-DSA 44 (Module-Lattice Digital Signature Algorithm, anciennement CRYSTALS-Dilithium) et Ed25519. ML-DSA 44 est l'un des algorithmes de signature numerique post-quantiques standardises par le NIST en 2024, concu pour resister aux attaques des ordinateurs quantiques.

L'approche hybride est strategique : au lieu de remplacer Ed25519 par ML-DSA 44, OpenSSH combine les deux algorithmes. Chaque signature contient a la fois une signature Ed25519 classique et une signature ML-DSA 44 post-quantique. Pour qu'un attaquant puisse forger une signature, il devrait casser les deux algorithmes simultanement. Cette strategie protege contre deux risques opposes : si un ordinateur quantique casse Ed25519, la signature ML-DSA 44 reste valide ; si une faiblesse est decouverte dans ML-DSA 44 (ce qui est possible pour un algorithme encore jeune), la signature Ed25519 reste solide. C'est le principe de la « ceinture et bretelles » cryptographique.

Le terme « harvest now, decrypt later » decrit une strategie d'attaque ou des acteurs etatiques interceptent et stockent du trafic chiffre aujourd'hui, en attendant de disposer d'un ordinateur quantique capable de le dechiffrer dans le futur. Les sessions SSH contiennent des donnees extremement sensibles : code source propriétaire, credentials de base de données, tokens API, cles privees. Meme si les ordinateurs quantiques capables de casser Ed25519 ne sont pas encore disponibles, les estimations des experts situent cette echeance entre 2030 et 2040. Pour les projets dont le code source doit rester confidentiel pendant des decennies (finance, defense, sante), la migration vers la cryptographie post-quantique doit commencer maintenant.

Actions immediates pour les developpeurs

Voici les etapes concretes a suivre pour securiser votre environnement de developpement. La priorite absolue est la mise a jour du client OpenSSH sur tous les postes de travail.

Etape 1 : Verifier votre version actuelle. Ouvrez un terminal et executez :

# Verifier la version OpenSSH installee
ssh -V
# Sortie attendue : OpenSSH_10.4p1, ...

# Si la version est inferieure a 10.4, mettre a jour :

# Debian / Ubuntu
sudo apt update && sudo apt install openssh-client openssh-server

# Fedora / RHEL
sudo dnf update openssh

# Arch Linux
sudo pacman -Syu openssh

# macOS (via Homebrew)
brew upgrade openssh

# Apres mise a jour du serveur, redemarrer sshd :
sudo systemctl restart sshd

Etape 2 : Auditer vos connexions SSH. Verifiez les serveurs auxquels vous vous connectez regulierement. Consultez votre fichier ~/.ssh/known_hosts et votre ~/.ssh/config. Pour chaque serveur, demandez-vous : est-ce que je fais confiance a l'infrastructure qui l'heberge ? Les serveurs de build CI/CD, les machines de staging, et les serveurs de clients sont les vecteurs d'attaque les plus probables pour les failles cote client.

Etape 3 : Durcir votre configuration SSH. Ajoutez ces lignes a votre ~/.ssh/config pour reduire la surface d'attaque :

# ~/.ssh/config - durcissement post-OpenSSH 10.4

Host *
    # Desactiver le forwarding d'agent par defaut
    ForwardAgent no
    # Verifier strictement les cles hotes
    StrictHostKeyChecking ask
    # Limiter les algorithmes aux plus recents
    KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
    HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
    # Desactiver les fonctions non utilisees
    ForwardX11 no
    # Timeout pour les connexions inactives
    ServerAliveInterval 60
    ServerAliveCountMax 3

Etape 4 : Mettre a jour vos serveurs. La mise a jour cote client est prioritaire, mais n'oubliez pas vos serveurs. Un serveur non patche n'est pas directement vulnerable aux failles de la 10.4 (qui sont cote client), mais il est essentiel de maintenir la coherence des versions dans votre infrastructure. De plus, chaque nouvelle version d'OpenSSH inclut des ameliorations de performance et de robustesse qui beneficient a l'ensemble de la chaine. Pour une approche structuree de la securite des cles SSH, consultez notre guide compagnon sur la securisation des cles SSH et l'authentification post-quantique.

Impact sur l'ecosysteme open source francais

Pour les developpeurs open source en France, ce bulletin OpenSSH a des implications directes sur le quotidien professionnel. GitHub, GitLab, Bitbucket — tous ces services utilisent SSH comme protocole de transport principal pour les operations Git. Chaque git push, chaque git pull, chaque git clone via SSH passe par le client OpenSSH installe sur votre poste. Si ce client est vulnerable, chaque operation Git devient un vecteur d'attaque potentiel.

L'ecosysteme des serveurs de production francais est particulierement concerne. Selon les donnees de Shodan, la France heberge plus de 2,3 millions de serveurs SSH accessibles publiquement. La majorite tourne sous Debian ou Ubuntu, ou les mises a jour OpenSSH passent par les depots officiels avec un delai de quelques jours a quelques semaines apres la publication upstream. Pour les administrateurs systeme qui gerent des parcs de serveurs, la mise a jour coordonnee de centaines de machines est un defi logistique — mais un defi necessaire.

La dimension post-quantique est egalement strategique pour la France. L'ANSSI (Agence nationale de la securite des systemes d'information) a publie des recommandations sur la migration vers la cryptographie post-quantique, avec un calendrier qui prevoit le debut de la transition pour les systemes critiques des 2025-2026. Le support ML-DSA 44 dans OpenSSH 10.4 s'inscrit directement dans ce calendrier. Les entreprises francaises soumises a des obligations de conformite (OIV, OSE, secteur bancaire) devraient commencer a evaluer le support post-quantique de leur infrastructure SSH des maintenant, meme si le deploiement en production n'est pas encore recommande.

Securiser vos pipelines CI/CD

Les failles sftp et scp d'OpenSSH 10.4 ont un impact direct sur les pipelines CI/CD qui utilisent ces protocoles pour transferer des artefacts. Un runner GitHub Actions ou GitLab CI qui se connecte a un serveur de build compromis via scp pourrait voir ses fichiers rediriges ou modifies en transit. Voici les actions recommandees :

Verifier la version OpenSSH dans vos images Docker CI/CD. La plupart des images de base (ubuntu:24.04, debian:12, alpine:3.20) incluent des versions d'OpenSSH qui peuvent ne pas encore inclure les correctifs de la 10.4. Ajoutez une etape explicite de verification dans vos workflows :

# .github/workflows/security-check.yml
- name: Verifier version OpenSSH
  run: |
    ssh -V 2>&1 | grep -E "OpenSSH_10.[4-9]|OpenSSH_1[1-9]" || {
      echo "::error::OpenSSH < 10.4 detecte - vulnerabilites sftp/scp/ssh"
      echo "::error::Mettre a jour l'image de base du runner"
      exit 1
    }

# Preferer rsync over ssh plutot que scp
- name: Transferer artefacts (securise)
  run: |
    rsync -avz -e "ssh -o StrictHostKeyChecking=yes" \
      ./build/ user@deploy-server:/app/

Remplacer scp par rsync. La commande scp est progressivement deprecee par l'equipe OpenSSH au profit de sftp ou rsync. Le path traversal corrige dans la 10.4 est une raison de plus pour migrer vos scripts de deploiement de scp vers rsync -e ssh, qui offre de meilleures garanties de validation des chemins et une reprise sur erreur. Pour une approche complete de la securisation de vos pipelines, consultez notre guide detaille sur la securisation des pipelines CI/CD GitHub Actions contre les attaques supply chain.

FAQ