Apache HTTP Server 2.4.71 corrige une exécution de code critique dans mod_http2

26 octobre 2026. Anthropic signale une faille critique au projet Apache. 3 novembre 2026. Google Cloud Vulnerability Research signale la même faille, indépendamment. 11 novembre 2026. Apache publie HTTP Server 2.4.71, qui corrige trois failles dont une exécution de code à distance sans authentification. Pourquoi c’est important : mod_http2 est chargé par défaut sur la plupart des serveurs qui servent de l’HTTP/2, et la faille ne demande rien d’autre qu’une requête atteignable par un client distant.

La faille : une course de threads dans assign_headers()

La vulnérabilité est enregistrée sous CVE-2026-119618, classée critique par l’équipe sécurité d’Apache. Son libellé NVD est précis : une « Concurrent Execution using Shared Resource with Improper Synchronization » — autrement dit une condition de course — dans la fonction assign_headers() du module mod_http2. Le résultat est une corruption du tas qui peut mener à l’exécution de code à distance.

Le mécanisme tient à la manière dont mod_http2 assemble les en-têtes d’une requête HTTP/2 avant de la transmettre au cœur du serveur. assign_headers() manipule une structure partagée entre threads sans synchroniser correctement les accès. Deux requêtes concurrentes, ou une séquence de frames soigneusement ordonnée, peuvent faire diverger l’état de cette structure : le serveur écrit alors dans une zone mémoire qu’il croit valide, et un attaquant qui contrôle le flot de frames peut transformer cette écriture en exécution de code.

La portée est large parce que le vecteur est banal. Il n’y a pas de précondition d’authentification, pas de module optionnel exotique, pas de réglage non standard : il suffit qu’HTTP/2 soit activé — et il l’est par défaut dès que mod_http2 est chargé. Les versions atteintes vont de 2.4.55 à 2.4.70 pour le serveur, et de 2.0.8 à 2.0.42 pour mod_h2, le dépôt GitHub qui porte le module de façon autonome.

Une précision rassurante pour ceux qui ont migré en frontal vers HTTP/3 : ce protocole n’est pas concerné. Il repose sur un module distinct, mod_http3, et une pile logicielle séparée. La faille vit dans le code qui parle HTTP/2, c’est-à-dire la très grande majorité des déploiements actuels — HTTP/3 reste minoritaire en frontal, et nombreux sont les parcs qui ne l’ont jamais activé. La bonne question pour trier son parc n’est donc pas « suis-je à jour ? », mais « quel protocole mon frontal sert-il réellement ? ».

Deux équipes, une même découverte

Ce qui rend ce lot remarquable n’est pas seulement sa gravité, c’est qui l’a trouvé. Deux entités indépendantes sont créditées comme finders dans l’annonce officielle :

• Anthropic, via son OSS Scanner, sous la référence interne ANT-2026-MAPKT6MZ — signalée le 26 octobre 2026 ;
• Anthony Weems et Simon Scannell du Google Cloud Vulnerability Research — signalée le 3 novembre 2026.

Autrement dit, un scanner automatisé de code open source piloté par un laboratoire d’IA et une équipe humaine de recherche en vulnérabilités sont arrivés, à huit jours d’écart, sur la même course de threads dans assign_headers(). C’est un signal concret de ce que l’analyse automatisée de code — celle que Anthropic déploie sur les dépôts open source — commence à produire sur des cibles aussi centrales que le serveur web le plus déployé au monde.

La coordination a été propre. Le correctif, commit 824beab dans la branche 2.4.x, est livré le 11 novembre 2026, le jour même de la publication de 2.4.71. Aucune exploitation en conditions réelles n’est documentée au moment de l’annonce, mais la fenêtre entre signalement et correctif — environ trois semaines pour le premier rapport — est le délai standard pour une faille de cette profondeur dans un projet de cette taille.

Deux autres failles dans le même correctif

2.4.71 n’embarque pas qu’une seule correction. Le lot en contient trois, de gravités décroissantes, et les deux autres méritent d’être connues parce qu’elles ciblent des modules très répandus.

CVE-2026-106023 — important. Un déréférencement de pointeur nul dans mod_md, le module qui gère la validation de domaine ACME (les certificats Let’s Encrypt). Une requête forgée peut faire planter le processus enfant — un déni de service qui, sur un serveur qui renouvelle ses certificats, devient gênant. Les versions 2.4.30 à 2.4.70 sont atteintes.

CVE-2026-109163 — low. Un débordement de tampon d’un octet dans mod_vhost_alias, qui complète un correctif antérieur (CVE-2026-63292, déjà traité dans notre analyse d’Apache 2.4.69). Seules les versions 2.4.69 et 2.4.70 sont concernées. La gravité est faible, mais elle rappelle que les correctifs « un octet » ont tendance à laisser des variantes derrière eux.

Qui est exposé : la vraie surface de mod_http2

La question opérationnelle n’est pas « suis-je sur Apache ? », c’est « est-ce que HTTP/2 est activé chez moi ? ». La réponse est presque toujours oui. Depuis 2.4.17, mod_http2 est fourni avec le serveur, et les distributions l’activent volontiers par défaut — Debian, Ubuntu, RHEL et leurs dérivés — parce que l’HTTP/2 améliore sensiblement la latence des pages. Red Hat, qui embarque le serveur dans RHEL, a publié son propre avis et rappelle que seuls les serveurs qui chargent mod_http2 sont atteints.

S’ajoute une catégorie qu’on oublie trop souvent : les reverse proxies et les équilibreurs de charge maison qui exposent un Apache en frontal, et les hébergeurs mutualisés qui servent des milliers de sites derrière un même binaire. Sur ces machines, une seule instance vulnérable est une porte d’entrée vers tout ce qui est derrière elle.

Vérifier et corriger en quelques minutes

La vérification tient en deux commandes. La première donne la version du binaire, la seconde indique si mod_http2 est chargé.

httpd -v
apachectl -M | grep -i http2

Si la version est antérieure à 2.4.71 et que http2_module apparaît, vous êtes exposé. La correction de fond est la mise à jour vers 2.4.71 — via le gestionnaire de paquets de la distribution, ou par recompilation si vous gérez mod_h2 depuis son dépôt GitHub, où la version corrigée correspond aux versions 2.0.8 à 2.0.42.

À l’échelle d’un parc, l’énumération est tout aussi simple : croiser l’inventaire de versions — CMDB, scanner d’infra — avec la plage vulnérable 2.4.55–2.4.70, et déclencher une alerte pour tout serveur qui y répond. Un réflexe utile pour les équipes qui gèrent des dizaines de frontaux : interroger l’en-tête Server renvoyé par chaque nœud exposé, qui trahit souvent la version exacte du binaire.

Pour ceux qui ne peuvent pas patcher immédiatement, le contournement est net : désactiver HTTP/2. Sur Debian ou Ubuntu, a2dismod http2 puis systemctl reload apache2 suffit. Sur les autres distributions, commentez la directive LoadModule http2_module et rechargez. Le coût est une perte de performance — les connexions repassent en HTTP/1.1 — mais c’est un prix bien inférieur à une exécution de code à distance.

Verdict

Si vous servez de l’HTTP/2 avec un Apache antérieur à 2.4.71 — frontal, reverse proxy ou hébergement mutualisé — mettez à jour vers 2.4.71 avant votre prochaine fenêtre de maintenance, ou désactivez mod_http2 dans l’heure si la mise à jour est bloquée. CVE-2026-119618 est une exécution de code à distance sans authentification sur le serveur web le plus déployé au monde, et l’absence d’exploitation publique constatée à ce jour ne change rien à l’équation : la fenêtre de correction est ouverte, il faut la prendre. Si HTTP/2 est désactivé chez vous — cas des parcs volontairement limités à HTTP/1.1 — le risque retombe au niveau des deux autres failles du lot, dont aucune n’est exploitable à distance sans conditions particulières : planifiez quand même la mise à jour dans votre cadence habituelle.

Références

• Apache — HTTP Server 2.4.71 security announcements (consultées le 12 novembre 2026)
• oss-security — « CVE-2026-119618: Apache HTTP Server: mod_http2: heap corruption and RCE in assign_headers » (Eric Covener, 11 novembre 2026)
• NVD — CVE-2026-119618 (publiée le 11 novembre 2026)
• ETTAYEB — notre analyse d’Apache 2.4.69 et de ses vingt correctifs