Apache HTTP Server 2.4.71, publié le 11/11/2026, corrige CVE-2026-119618, une vulnérabilité critique du module HTTP/2 qui peut permettre à un attaquant distant non authentifié d’exécuter du code sur le serveur. Elle touche les versions 2.4.55 à 2.4.70 lorsque HTTP/2 est activé, une configuration courante dans l’hébergement, les proxys inverses et les passerelles applicatives.
Les points clés de la faille CVE-2026-119618 d’Apache en 20 secondes
- Elle touche Apache 2.4.55 à 2.4.70 avec HTTP/2 (h2 ou h2c) activé.
- Elle peut permettre l’exécution de code à distance sans authentification ; Red Hat lui attribue un score CVSS de 9,8.
- Le correctif est la version 2.4.71 ou le paquet corrigé de la distribution.
- En attendant, on peut limiter Protocols à http/1.1.
La faille est une condition de concurrence dans la fonction assign_headers() de mod_http2 : des requêtes HTTP/2 simultanées peuvent corrompre la mémoire du processus. Elle a été découverte de façon indépendante par l’outil OSS Scanner d’Anthropic et par deux chercheurs de Google Cloud Vulnerability Research. Red Hat assure qu’une recherche publique a démontré un exploit fiable contre des configurations par défaut, sans l’identifier, alors que Wiz n’avait connaissance ni d’exploits disponibles ni d’attaques. Chez OpenSecurity, nous avons publié l’analyse technique complète de CVE-2026-119618, avec les commandes pour vérifier l’exposition.
Pourquoi cela compte dans l’hébergement et le cloud
Apache HTTP Server reste une pièce centrale de nombreux services d’hébergement, panneaux de contrôle, répartiteurs de charge et back-ends placés derrière des proxys. HTTP/2 est souvent activé pour la performance, puis oublié, et la plage concernée est large : la 2.4.55 est sortie en janvier 2023. De plus, ceux qui ont mis à jour en mai vers la 2.4.67 pour corriger une autre faille grave de HTTP/2, CVE-2026-23918, restent exposés à celle-ci.
Sur les plateformes avec images de conteneurs ou modèles de machines virtuelles, le risque se trouve dans les copies que l’on ne reconstruit pas : mettre à jour le paquet sur les serveurs en production ne corrige pas les images de base dont sortiront les prochains déploiements. Il faut aussi vérifier où se termine la connexion HTTP/2 : si un répartiteur de charge ou un CDN la termine et parle HTTP/1.1 avec Apache, le back-end n’est pas atteignable par cette voie ; si le HTTP/2 arrive jusqu’à Apache, il l’est.
État des correctifs par distribution
Red Hat a déjà publié des paquets corrigés de mod_http2 pour RHEL 9 et 10, et précise que RHEL 6, 7 et 8 ne sont pas concernés ; sur ses systèmes, elle qualifie la faille d’« importante » parce que sa compilation alloue la mémoire par flux HTTP/2, ce qui complique l’exploitation. Debian avait le correctif dans sid et les autres versions étaient en cours de traitement, Amazon Linux l’avait en attente et Ubuntu n’avait pas publié d’avis au moment de la divulgation de la vulnérabilité. Sur Ubuntu 22.04 et 24.04, le paquet inclut un mod_http2 rétroporté, si bien que le numéro de version d’Apache ne suffit pas à écarter le risque. Cette disparité entre distributions rappelle ce que l’on observe pour d’autres composants, comme l’état des correctifs PHP dans les distributions et les panneaux.
Le mod_h2 indépendant de GitHub (2.0.8 à 2.0.42) est lui aussi touché et ne recevra pas de correctif, car le dépôt est archivé depuis juin. La version 2.4.71 corrige par ailleurs un arrêt inattendu dans mod_md et un écrasement d’un octet dans mod_vhost_alias.
Si la mise à jour immédiate est impossible, Wiz recommande de laisser la directive Protocols sur http/1.1, aussi bien dans la configuration globale que dans chaque hôte virtuel qui la redéfinit, ou de désactiver mod_http2. Cela suppose de renoncer temporairement à HTTP/2, mais élimine la surface d’attaque.
Questions fréquentes
Quelles versions d’Apache sont concernées ?
Apache HTTP Server 2.4.55 à 2.4.70 avec HTTP/2 activé, ainsi que le mod_h2 indépendant 2.0.8 à 2.0.42.
Suis-je concerné si j’utilise un répartiteur de charge ou un CDN en amont ?
Cela dépend de l’arrivée ou non du trafic HTTP/2 jusqu’à Apache. Si le répartiteur termine HTTP/2 et parle HTTP/1.1 avec le back-end, la faille n’est pas atteignable par cette voie.
Que faire si je ne peux pas encore mettre à jour ?
Limiter la directive Protocols à http/1.1 ou désactiver mod_http2 jusqu’à pouvoir installer la 2.4.71 ou le paquet corrigé.
Sources :
