Faille HTTP/2 Apache CVE-2026-119618 : passez à la 2.4.71

Qu'est-ce que la faille CVE-2026-119618 ?

CVE-2026-119618 est une vulnérabilité critique de mod_http2, le module qui gère le trafic HTTP/2 dans Apache HTTP Server ; elle peut entraîner une corruption du tas et l'exécution de code à distance ^[1].

Apache la décrit comme une « vulnérabilité d'exécution concurrente utilisant une ressource partagée avec une synchronisation incorrecte dans mod_http2 d'Apache HTTP Server, dans assign_headers() » qui « peut mener à une RCE » ^[1]. Le CIRCL, l'équipe nationale de réponse aux urgences informatiques du Luxembourg, explique que lors du traitement concurrent de flux HTTP/2, un worker peut modifier une table d'en-têtes allouée pour un autre contexte d'exécution, et que cet accès non sûr à la mémoire partagée peut corrompre le tas ^[2].

Un attaquant qui réussirait pourrait exécuter du code avec les privilèges du processus du serveur web Apache, sans s'authentifier ^[2][4]. Selon BleepingComputer, Apache HTTP Server ferait tourner environ un site web sur cinq ^[4].

Le correctif amont modifie une seule écriture dans modules/http2/h2_request.c, de la table d'en-têtes de requête partagée vers les propres en-têtes d'entrée de la requête en cours ^[2].

Quelles versions d'Apache sont concernées ?

Apache HTTP Server 2.4.55 à 2.4.70 est concerné, de même que les versions autonomes de mod_h2 2.0.8 à 2.0.42 disponibles sur GitHub ; la version 2.4.71 corrige la faille ^[1].

Les paquets de distribution compliquent la vérification de version. Le CIRCL conseille aux organisations qui utilisent des paquets maintenus par les distributeurs de vérifier le rétroportage de sécurité plutôt que de se fier uniquement au numéro de version amont ^[2]. Red Hat, tel que résumé par le CIRCL, classe ses paquets RHEL 9 et 10 en Important plutôt qu'en Critique parce que leur allocateur mémoire rend l'exploitation plus difficile, et indique que RHEL 8 et les versions antérieures ne sont pas concernés ^[2].

Red Hat attribue un score CVSS v3.1 général de 9,8 (Critique) ^[2][3]. La propre évaluation d'Apache est Critique ^[1].

Mon serveur Apache est-il vulnérable ?

Seulement s'il exécute une version concernée et accepte réellement des connexions HTTP/2 : Red Hat indique que les serveurs configurés pour servir uniquement du HTTP/1.1 ne sont pas vulnérables ^[3]. Le CIRCL insiste sur le fait que le chemin de code n'est pas atteignable du simple fait que mod_http2 est installé ou chargé ^[2].

• La directive Protocols contrôle HTTP/2 : « h2 » l'active sur TLS et « h2c » en clair ^[2].
• La valeur par défaut du cœur d'Apache est http/1.1, et le chargement de mod_http2 ne la modifie pas à lui seul ^[2]. BleepingComputer note que HTTP/2 est désactivé par défaut ^[4].
• Un hôte virtuel peut définir sa propre directive Protocols ; ne vérifier que la configuration globale peut donc faire passer à côté d'un site avec HTTP/2 activé ^[2].
• Si un reverse proxy, un répartiteur de charge ou un CDN termine HTTP/2 et ne transmet que du HTTP/1.1 à Apache, la session HTTP/2 du client ne rend pas Apache atteignable à elle seule, mais il faut vérifier le protocole à chaque saut ^[2].

Le CIRCL suggère de revoir la version et les modules chargés (apachectl -v, apachectl -M), les hôtes virtuels configurés (apachectl -S) et chaque réglage Protocols explicite ^[2]. Un test montrant qu'un point d'accès accepte HTTP/2 ne prouve pas que son backend est vulnérable, et un test négatif ne prouve pas que chaque port ou hôte virtuel rejette HTTP/2 ^[2].

Comment vérifier si mon serveur accepte HTTP/2 ?

Le CIRCL suggère deux vérifications : examiner la configuration d'Apache sur le serveur lui-même, puis tester le protocole négocié depuis le réseau, idéalement en se connectant directement à Apache plutôt que via un proxy ^[2].

1. Vérifier la version et les modules. Exécutez apachectl -v pour voir la version et apachectl -M, filtré sur http2, pour voir si le module est chargé ^[2].
2. Lister les hôtes virtuels. apachectl -S affiche chaque hôte virtuel configuré, ce qui compte car chacun peut avoir sa propre ligne Protocols ^[2].
3. Trouver chaque directive Protocols. Le CIRCL fournit une commande grep qui parcourt /etc/apache2 et /etc/httpd à la recherche de réglages Protocols explicites, y compris les surcharges d'hôtes virtuels ; les chemins varient selon la distribution ^[2].
4. Tester sur TLS. Une requête curl avec l'option --http2 qui affiche la version HTTP montre si un point d'accès HTTPS négocie HTTP/2 ^[2].
5. Tester en clair. curl avec --http2-prior-knowledge vérifie si un point d'accès HTTP simple accepte h2c ^[2].

Lisez les résultats avec prudence. Une réponse indiquant HTTP/2 montre que le point d'accès testé a accepté HTTP/2 mais ne confirme pas que son backend Apache est vulnérable ; un résultat négatif ne prouve pas que chaque adresse, port ou hôte virtuel le rejette ^[2]. Le conseil du CIRCL est de confirmer ensemble la configuration effective d'Apache et l'état des paquets corrigés du fournisseur ^[2]. Dans les environnements cloud, Wiz avertit qu'une instance Apache compromise peut devenir un point d'entrée pour des mouvements latéraux vers des microservices voisins ou des points d'accès aux métadonnées cloud, une raison de plus de vérifier chaque instance et pas seulement le site web public ^[5].

Comment corriger CVE-2026-119618 ?

Passez à Apache HTTP Server 2.4.71 ou à une version ultérieure, ou installez le paquet corrigé de votre distribution, puis redémarrez Apache et vérifiez que les processus en cours utilisent la nouvelle version ^[2][1].

1. Mettre Apache à jour. Installez la 2.4.71 ou une version du fournisseur explicitement corrigée pour CVE-2026-119618 ^[2].
2. Mettre à jour mod_h2 autonome si vous l'utilisez, selon les indications de son éditeur ; Wiz recommande de dépasser la 2.0.42, tandis que le CIRCL met en garde contre l'hypothèse qu'une version autonome plus récente existe sans vérification ^[5][2].
3. Redémarrer et vérifier que les processus en cours utilisent la version corrigée ^[2].
4. Si vous ne pouvez pas encore corriger, désactivez HTTP/2 : définissez Protocols sur http/1.1, retirez h2 et h2c de chaque hôte virtuel qui les surcharge, testez avec apachectl -t et rechargez ^[2]. Cela bloque le chemin de cette faille sans corriger le code ^[2].
5. Restreindre l'accès aux réseaux de confiance à titre provisoire lorsque ni la correction ni le changement de protocole ne sont possibles ^[2].

Les chercheurs de watchTowr l'ont résumé ainsi : « corrigez maintenant ou abandonnez h2 jusqu'à ce que vous le puissiez », rapporte BleepingComputer ^[4]. SecurityWeek rapporte que Defiant a aussi averti que les mises à jour de sécurité de WordPress ne peuvent pas résoudre le problème, car il touche le serveur web sous-jacent ^[3].

CVE-2026-119618 est-elle exploitée ?

À la date de l'article de Wiz du 11 novembre 2026, aucun exploit n'était disponible et aucune exploitation dans la nature n'avait été signalée ^[5]. La situation évolue toutefois rapidement.

• Red Hat indique que des recherches publiques ont démontré un exploit fiable contre un serveur avec mod_http2 activé, mais son avis n'identifie pas ces recherches ^[3]. Le CIRCL note que cela n'établit pas, à soi seul, une exploitation dans la nature ^[2].
• Une preuve de concept publique sur GitHub indique reproduire des corruptions de mémoire et des plantages d'Apache, mais ne démontre pas d'exécution de code à distance ^[3].
• Les données de Wiz montrent que 64 % des environnements cloud contiennent des ressources exécutant des versions concernées et que 51 % ont des instances exposées publiquement ; Wiz précise que cela ne tient pas compte de la configuration, et que ce ne sont donc pas nécessairement des systèmes exploitables ^[5][3].

Le CIRCL énumère des signes à examiner : plantages inattendus de workers, redémarrages anormaux, processus enfants suspects, modifications de fichiers non autorisées et connexions sortantes inattendues ^[2]. Ce sont des pistes, pas des indicateurs de compromission confirmés, et la correction ne supprime pas la persistance installée avant la mise à jour ^[2].

Qui a découvert la faille HTTP/2 d'Apache ?

Apache crédite l'OSS Scanner d'Anthropic, qui a signalé la faille le 26 octobre 2026, ainsi qu'Anthony Weems et Simon Scannell de Google Cloud Vulnerability Research, qui l'ont signalée indépendamment le 3 novembre ^[1].

La découverte d'Anthropic est répertoriée sous l'identifiant interne ANT-2026-MAPKT6MZ ^[1]. SecurityWeek décrit les deux signalements comme des découvertes indépendantes ^[3]. C'est un nouvel exemple d'outils automatisés et assistés par l'IA qui trouvent de graves bugs dans des logiciels open source très répandus ; AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You examine ce que cette tendance signifie.

Le correctif a été validé et la 2.4.71 publiée le 11 novembre, le jour même où Apache a divulgué le problème sur la liste de diffusion oss-security ^[1][2].

Que corrige d'autre Apache 2.4.71 ?

Apache HTTP Server 2.4.71 corrige trois CVE au total : une critique, une importante et une faible ^[1].

• CVE-2026-106023 (importante) : un déréférencement de pointeur NULL dans mod_md pendant le traitement d'une requête, qui peut faire planter un processus enfant ; touche la 2.4.30 à la 2.4.70 ^[1].
• CVE-2026-109163 (faible) : un écrasement d'un octet de tampon de pile dans mod_vhost_alias, qu'Apache qualifie de « suite de CVE-2026-63292 » (cette faille antérieure a été corrigée en 2.4.69) ; touche les versions 2.4.69 et 2.4.70 ^[1].

La version précédente, la 2.4.69 d'octobre 2026, corrigeait 20 CVE ^[1]. Les administrateurs qui l'ont sautée bénéficient aussi de ces correctifs en passant à la 2.4.71. Pour une autre faille récente touchant les serveurs, voir CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers.

Que doivent surveiller ensuite les administrateurs ?

Surveillez l'arrivée d'un exploit public d'exécution de code à distance, les rétroportages de votre distribution et tout signalement d'attaques dans la nature ^[3][5].

Le CIRCL recommande d'inventorier les instances avec HTTP/2 activé, de vérifier si chaque version de mod_http2 est concernée et de corriger sans délai les systèmes exposés, en priorité les sites web et API accessibles depuis Internet, les hébergements mutualisés et les serveurs Apache placés derrière des frontaux qui transmettent HTTP/2 ^[2]. Les organisations qui constatent une activité suspecte doivent suivre leurs procédures de réponse aux incidents et contacter leur CSIRT national ^[2].