Votre serveur Apache répond en HTTP/2 ? Une faille critique dans le module mod_http2 peut permettre à un attaquant non authentifié d’exécuter du code à distance. La version 2.4.71 corrige le problème, mais qui peut réellement en profiter ? Voici ce qu’il faut savoir.
Le 11 novembre 2026, la fondation Apache a publié une nouvelle version de son serveur web : Apache HTTP Server 2.4.71. Cette version corrige trois failles de sécurité, dont la CVE-2026-119618, une vulnérabilité critique. D’après le bulletin de sécurité, cette faille se situe dans la fonction assign_headers() du module mod_http2. Elle est associée à une race condition : plusieurs traitements exécutés en parallèle modifient la même zone mémoire sans se coordonner. Selon l’ordre dans lequel ils s’exécutent, cette mémoire peut être corrompue. Dans son rapport, Wiz précise qu’un attaquant distant et non authentifié peut corrompre la mémoire pour exécuter du code avec les privilèges du processus du serveur Web.
Les versions 2.4.55 (dont la sortie remonte à janvier 2023) à 2.4.70 d’Apache HTTP Server sont affectées, ainsi que les versions 2.0.8 à 2.0.42 de mod_h2, la déclinaison autonome du module distribuée sur GitHub. Pour qu’un serveur soit vulnérable, le module mod_http2 doit être chargé et HTTP/2 activé via la directive Protocols, avec la valeur h2 (HTTP/2 sur TLS) ou h2c (HTTP/2 en clair).
Il est intéressant de noter que cette vulnérabilité a été signalée le 26 octobre 2026 par l’OSS Scanner d’Anthropic, un service gratuit d’analyse de projets open source basé sur l’IA. Anthony Weems et Simon Scannell, de l’équipe Google Cloud Vulnerability Research, l’ont signalée de leur côté le 3 novembre, de façon indépendante. Elle était donc destinée à être découverte !
Exploit public ou pas ? Red Hat et Wiz ne sont pas d’accord
“Des recherches publiques ont démontré un exploit fiable”, affirme Red Hat sur sa page dédiée à la faille, à propos d’un serveur en configuration par défaut avec mod_http2 activé. Toutefois, Red Hat, qui attribue un score CVSS de 9,8 sur 10 à cette faille, ne précise pas de quelles recherches il s’agit. Wiz, de son côté, indiquait le 11 novembre qu’aucun exploit n’était disponible et qu’aucune exploitation active n’avait été signalée.
Depuis, une preuve de concept (PoC) a été publiée sur GitHub. Elle démontre la corruption de la mémoire sur la version 2.4.70, et son absence sur la 2.4.71, mais pas l’exécution de code. Sur GitHub, le dépôt est particulièrement bien détaillé, avec des détails techniques et des informations pour reproduire l’environnement de test. C’est à suivre.
Comment se protéger de la CVE-2026-119618 ?
Il faut passer à Apache HTTP Server 2.4.71, ou à un paquet qui intègre le correctif : le bulletin d’Apache ne propose aucune solution de contournement. En pratique, vous dépendez surtout de votre distribution et de la mise à disposition de ce paquet :
Red Hat Enterprise Linux 9 et 10 : selon Red Hat, les correctifs sont livrés dans les paquets mod_http2-2.0.26-7.el9_9.1 et mod_http2-2.0.29-5.el10_3.1. C’est ce paquet, distinct de httpd, qu’il faut mettre à jour avant de redémarrer httpd (vérifiez avec rpm -q mod_http2, car httpd -v ne changera pas de version).
Debian : d’après le suivi de sécurité Debian, bookworm, trixie et forky sont vulnérables. Le correctif est disponible dans le dépôt Security de Trixie.
Amazon Linux : correctif en attente pour Amazon Linux 2, 2023 et 2027 Preview, selon Amazon Linux.
Ubuntu : Canonical n’avait publié aucune page de suivi pour cette CVE.
Je vous confirme que le patch est bien disponible sur Debian 13.
sudo apt list –upgradable
apache2-bin/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]
apache2-data/stable-security 2.4.71-1~deb13u1 all [upgradable from: 2.4.69-1~deb13u1]
apache2-utils/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]
apache2/stable-security 2.4.71-1~deb13u1 amd64 [upgradable from: 2.4.69-1~deb13u1]
En attendant, Wiz conseille de désactiver HTTP/2. Vérifiez si le module est chargé, puis repérez chaque occurrence de la directive Protocols (globale et par VirtualHost) :
sudo apachectl -M | grep -w http2_module
grep -Rni “Protocols” /etc/apache2/ /etc/httpd/ 2>/dev/null
Retirez ensuite h2 et h2c de chaque occurrence pour ne conserver que :
Protocols http/1.1
Vous pouvez aussi désactiver le module directement pour ne plus le charger, avec a2dismod http2 sous Debian et Ubuntu. Les clients basculeront en HTTP/1.1, un compromis acceptable le temps de patcher, même si pour l’instant rien n’indique que cette faille soit exploitée.
Cet article est aussi l’occasion de rappeler les précédentes et récentes failles patchées dans Apache2 :
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.