Apache corrige une RCE critique dans mod_http2 (CVE-2026-119618)
Apache HTTP Server 2.4.71 corrige CVE-2026-119618, un bug de synchronisation dans mod_http2 noté 9,8 par Red Hat : RCE pré-auth sur les versions 2.4.55 à 2.4.70 avec HTTP/2 actif.
Apache a publié le 11 novembre la version HTTP Server 2.4.71, qui corrige CVE-2026-119618, une corruption mémoire dans le module mod_http2. Le projet classe la faille critique et Red Hat lui attribue un score CVSS de 9,8. Un attaquant qui atteint un serveur avec HTTP/2 activé, sans aucun identifiant, pourrait exécuter du code. La faille a été relevée côté francophone par Next.
Ce que fait la faille
L'avis Apache décrit une « Concurrent Execution using Shared Resource with Improper Synchronization » dans assign_headers() : une ressource partagée est utilisée sans synchronisation correcte, un thread écrase la mémoire d'un autre et corrompt le tas. Le résultat peut mener à l'exécution de code à distance. L'éditeur de sécurité Wiz précise un point qui compte pour l'évaluation du risque : l'exécution se ferait avec les privilèges du processus de travail (www-data, apache…), pas directement root.
La condition d'exposition est simple : HTTP/2 doit être activé via la directive Protocols (valeurs h2 ou h2c). Un serveur en HTTP/1.1 seul n'est pas concerné.
Versions concernées
- Apache HTTP Server : de 2.4.55 à 2.4.70. Corrigé en 2.4.71.
mod_h2autonome (les versions distribuées séparément) : de 2.0.8 à 2.0.42.- Non concernés : les serveurs en HTTP/1.1 uniquement, et
mod_http2antérieur à 2.0.8.
La 2.4.67, qui corrigeait une faille HTTP/2 précédente, reste vulnérable à celle-ci. La 2.4.71 corrige par ailleurs deux autres problèmes : un défaut important dans mod_md et un défaut faible dans mod_vhost_alias.
Côté distributions, l'état des correctifs est inégal : Red Hat a corrigé toutes ses versions supportées (gravité ramenée à « importante » pour RHEL 9 et 10, chaque flux HTTP/2 y disposant de son propre allocateur mémoire), Arch Linux, Alpine et AlmaLinux ont publié un correctif, Debian Sid est corrigée mais Bookworm et Trixie ne l'étaient pas à la publication, et Ubuntu comme Fedora n'avaient pas encore de paquet.
Statut d'exploitation
Pas d'exploitation confirmée dans la nature. Les lectures divergent sur la proximité de la menace : Red Hat affirme que des « travaux publics ont démontré une exploitation fiable » sur une configuration par défaut avec mod_http2, tandis que Wiz indique qu'aucun code d'exploitation n'était disponible et qu'aucune attaque n'avait été signalée. À traiter comme une RCE 9,8 en configuration par défaut, en phase pré-exploitation : la fenêtre est courte.
La faille a d'abord été remontée par un outil d'analyse automatisé d'Anthropic, puis indépendamment par Anthony Weems et Simon Scannell, de Google Cloud Vulnerability Research.
Que faire
- Inventoriez HTTP/2. Cherchez dans vos configurations les lignes
Protocolscontenanth2ouh2c. Les serveurs en HTTP/1.1 seul sont hors périmètre. - Passez en 2.4.71 (ou au paquet
mod_http2corrigé de votre distribution) sur chaque frontal et reverse proxy exposant HTTP/2. - Pas de patch aujourd'hui ? Désactivez HTTP/2. Le contournement de Wiz consiste à retirer
h2eth2cde la directiveProtocols, à ne garder queProtocols http/1.1, puis à recharger. La surface d'attaque disparaît, au prix de la performance HTTP/2. - N'oubliez pas l'Apache embarqué. Appliances, répartiteurs de charge et produits tiers qui embarquent httpd avec HTTP/2 actif sont ceux qui resteront vulnérables le plus longtemps.
- Si vous utilisez
mod_h2autonome, reconstruisez à partir du correctif amont : il n'y a pas de version taguée à récupérer.
Lecture
C'est la deuxième faille de type RCE dans mod_http2 ce cycle : les serveurs restés en 2.4.67 à 2.4.70 ont corrigé un premier bug HTTP/2 pour rester exposés à celui-ci. La machine à états par connexion de HTTP/2 continue de produire des bugs mémoire sous forte concurrence, et le schéma de découverte se répète — un scanner automatisé, ici celui d'Anthropic, qui remonte la faille aux côtés de chercheurs humains. L'analyse assistée par machine fait désormais partie du pipeline de divulgation pour ce protocole, et la cadence des correctifs s'accélère en conséquence. Pour les équipes qui opèrent du web à l'échelle, « patcher le serveur » doit vouloir dire patcher le module HTTP/2 en particulier.