Apache corrige une faille qui permet de pirater des serveurs HTTP/2 sans connexion

12.11.2026 4 min 6

Le projet Apache HTTP Server a publié la version 2.4.71 le 11 novembre. Elle corrige une faille critique dans mod_http2, le module qui gère les connexions HTTP/2. Selon le bulletin d'Apache, la faille CVE-2026-119618 peut mener à l'exécution de code à distance et touche toutes les versions de 2.4.55 à 2.4.70. Un attaquant qui peut joindre le serveur n'a besoin ni de mot de passe ni de compte.

En bref

  • Seuls les serveurs avec HTTP/2 activé (h2 ou h2c dans la directive Protocols) sont exposés. Ceux qui ne parlent que HTTP/1.1 ne le sont pas.
  • Red Hat note la faille 9,8 sur 10. Ses paquets pour RHEL 9 et 10 sont plus difficiles à attaquer, car chaque flux HTTP/2 y a son propre allocateur mémoire, et RHEL 8 et les versions plus anciennes ne contiennent pas le code vulnérable.
  • Debian n'a corrigé pour l'instant que sa branche unstable, et Amazon Linux indique un correctif en attente.
9,8score CVSS selon Red Hat et Amazon
2.4.55-2.4.70versions d'Apache touchées
2.4.71version corrigée, sortie le 11 novembre

Ce qui ne va pas dans mod_http2

HTTP/2 permet à un navigateur d'envoyer de nombreuses requêtes à la fois sur une seule connexion, et mod_http2 les traite dans plusieurs threads. Red Hat explique qu'il s'agit d'une situation de concurrence dans la fonction assign_headers() : un thread de travail peut écrire dans la mémoire du thread de connexion via un allocateur partagé sans verrou. La mémoire du serveur est alors corrompue, et un attaquant peut s'en servir pour lancer ses propres commandes et prendre le contrôle du processus du serveur.

D'après Red Hat, une recherche publique « a démontré un exploit fiable » contre un serveur en configuration par défaut avec mod_http2 activé, sans préciser laquelle. The Hacker News rapporte que la société de sécurité Wiz a indiqué le même jour qu'aucun exploit n'était disponible et qu'aucune attaque n'avait été observée. Dans les deux cas, les détails sont désormais publics, et les administrateurs n'ont pas intérêt à attendre qu'un exploit fonctionnel apparaisse.

La faille a été signalée à Apache le 26 octobre par l'OSS Scanner d'Anthropic, un service gratuit qui analyse les projets open source avec les modèles d'IA de l'entreprise. Anthony Weems et Simon Scannell, de Google Cloud Vulnerability Research, l'ont trouvée de leur côté et signalée le 3 novembre. La version 2.4.71 corrige aussi un plantage de mod_md, jugé important, et l'écrasement d'un octet de pile dans mod_vhost_alias, jugé faible.

Qui a déjà un correctif

Les distributions Linux compilent leur propre Apache avec leurs propres numéros de paquets, le bon correctif dépend donc du système. État au 12 novembre :

SystèmeÉtat
Apache 2.4.71 du projetCorrigé
Red Hat Enterprise Linux 9 et 10Corrigé (paquets mod_http2 du 11 novembre)
Red Hat Enterprise Linux 6, 7 et 8Non concernés
Debian unstable (sid)Corrigé dans apache2 2.4.71-1
Debian bookworm, trixie et forkyVulnérables, pas encore de correctif
Amazon Linux 2, 2023 et 2027 PreviewCorrectif en attente

Les versions autonomes du module, publiées sur GitHub sous le nom mod_h2, sont touchées de 2.0.8 à 2.0.42. Ce dépôt est archivé depuis juin et n'a aucune version corrigée. En mai, Apache avait corrigé une autre faille HTTP/2, CVE-2026-23918, dans la 2.4.67 : les serveurs mis à jour à ce moment-là restent exposés à la nouvelle. Le mois dernier, NGINX a corrigé des failles similaires qui permettaient elles aussi d'exécuter du code sans connexion.

Comment vérifier votre serveur

  • apachectl -v affiche la version, et apachectl -M | grep http2 indique si mod_http2 est chargé.
  • Cherchez la directive Protocols dans la configuration, au niveau global et dans chaque hôte virtuel. Si elle contient h2 ou h2c, le serveur parle HTTP/2.
  • Installez la mise à jour de votre distribution dès sa sortie, ou passez à la 2.4.71 si vous compilez Apache vous-même.
  • Si la mise à jour est impossible pour l'instant, Wiz conseille de ne garder que Protocols http/1.1. Les sites seront un peu plus lents, mais le code vulnérable ne s'exécutera pas.

apachevulnérabilitéserveurslinuxmise à jour de sécuritéred hatdebiancybersécuritéanthropic

À lire aussi