Les administrateurs de serveurs Apache HTTP disposent d'un correctif pour une vulnérabilité qui pourrait permettre à des attaquants distants d'exécuter des commandes sans authentification lorsque HTTP/2 est activé. La version 2.4.71, publiée le 11 novembre, corrige la faille CVE-2026-119618. Selon l'évaluation de Red Hat, une exploitation pourrait donner aux attaquants le contrôle du processus serveur, leur permettant d'accéder à des données, de les modifier et de perturber le service.
Les versions d'Apache concernées vont de 2.4.55 à 2.4.70, selon The Hacker News, qui en a fait état le 12 novembre. L'exposition nécessite HTTP/2 : un serveur ne traitant que du trafic HTTP/1.1 n'est pas concerné. Les organisations qui utilisent les paquets de distributions Linux doivent consulter les informations de publication de leur éditeur, car ces paquets portent des numéros de version distincts et des correctifs propres.
Red Hat attribue à la vulnérabilité un score de gravité CVSS de 9,8 sur 10 et la classe globalement Critique, avec des niveaux inférieurs pour certains produits. Dans son évaluation du 11 novembre, l'éditeur indique que des recherches publiques ont démontré une exploitation fiable d'un serveur en configuration par défaut, avec mod_http2 activé. The Hacker News a également relayé une déclaration contradictoire de la société de sécurité Wiz, plus tard dans la journée : aucun exploit n'était disponible et aucune exploitation dans la nature n'avait été signalée.
La configuration détermine l'exposition
Les administrateurs peuvent vérifier si HTTP/2 est actif en examinant la directive Protocols d'Apache. La valeur h2 active le protocole sur TLS, qui chiffre la connexion, tandis que h2c l'active sur TCP non chiffré. Ces réglages peuvent s'appliquer à l'ensemble du serveur ou à des hôtes virtuels individuels, c'est-à-dire aux configurations utilisées pour servir des sites distincts. Il faut donc vérifier les deux niveaux.
HTTP/2 transporte plusieurs requêtes simultanément sur une même connexion. Dans Apache, mod_http2 répartit ce travail entre des threads, c'est-à-dire des chemins d'exécution distincts à l'intérieur du processus serveur. Red Hat décrit une erreur de gestion de la mémoire : un worker traitant une requête écrit dans une zone mémoire appartenant au thread qui gère la connexion.
Les threads partagent un allocateur sans verrou, c'est-à-dire un mécanisme qui attribue la mémoire sans coordonner l'accès par des verrous. Cette interaction défaillante corrompt la mémoire interne et peut permettre à un attaquant disposant d'un accès réseau au serveur d'exécuter des commandes, sans identifiants ni interaction de l'utilisateur.
Le mode de packaging change la difficulté de cette attaque. Selon Red Hat, Red Hat Enterprise Linux (RHEL) 9 et 10 attribuent un allocateur distinct à chaque flux HTTP/2, ce qui complique nettement l'exploitation. Ces versions reçoivent une note Important plutôt que Critique. Le code vulnérable a été introduit dans mod_http2 2.0.8 ; les versions antérieures du module, ainsi que RHEL 8 et les versions plus anciennes, ne sont pas touchées.
Les builds autonomes de mod_h2 distribués via GitHub sont vulnérables de la version 2.0.8 à la 2.0.42. Au 12 novembre, date du rapport, la liste des versions s'arrêtait à la 2.0.42, sans correctif autonome disponible. Le dépôt a été archivé le 9 juin et est en lecture seule depuis.
Le média The Hacker News date au 26 octobre un signalement de la faille effectué via l'OSS Scanner d'Anthropic. Ce service gratuit analyse des projets open source à l'aide des modèles d'IA d'Anthropic. Le média indique également que les chercheurs Anthony Weems et Simon Scannell, de Google Cloud Vulnerability Research, ont signalé le problème « la semaine dernière ». Red Hat reconnaît les deux chercheurs.
Choisir le correctif pour la version déployée
Pour les installations utilisant les versions d'Apache elles-mêmes, les administrateurs doivent installer la 2.4.71, la version corrigée identifiée dans l'avis de sécurité d'Apache, selon The Hacker News. Elle corrige également un plantage de mod_md classé Important et une écriture d'un octet dans la mémoire de pile de mod_vhost_alias, classée Faible.
Un correctif HTTP/2 antérieur ne suffit pas : Apache 2.4.67, publiée le 4 mai, corrigeait la CVE-2026-23918, mais cette version et les suivantes, jusqu'à la 2.4.70 incluse, restent dans la plage touchée par la nouvelle faille.
Red Hat a publié des mises à jour le 11 novembre. Les paquets et avis listés dans le rapport de The Hacker News sont les suivants :
- RHEL 9 :
mod_http2-2.0.26-7.el9_9.1, couvert par RHSA-2026:98981. - RHEL 10 :
mod_http2-2.0.29-5.el10_3.1, couvert par RHSA-2026:98978. - RHEL 9.4 Update Services for SAP Solutions : un correctif sous RHSA-2026:98968.
- RHEL 9.6, 9.8, 10.0 et 10.2 Extended Update Support : des correctifs sous RHSA-2026:98954, RHSA-2026:98982, RHSA-2026:98953 et RHSA-2026:98979, respectivement. Les administrateurs doivent obtenir le paquet indiqué dans l'avis de leur version.
Le rapport liste Red Hat JBoss Core Services et Red Hat Hardened Images comme concernés, sans correctif indiqué. Red Hat met également en garde : les produits construits sur des composants touchés, y compris les offres basées sur des conteneurs, peuvent être exposés sans figurer séparément dans son tableau des produits concernés.
Par ailleurs, la disponibilité des correctifs restait inégale le 12 novembre. The Hacker News, citant le suivi de sécurité de Debian, indique que la branche instable, aussi appelée sid, est corrigée dans apache2 2.4.71-1. Debian bookworm, trixie et forky sont signalées vulnérables, sans correctif listé. Le suivi d'Amazon indiquait des correctifs en attente pour Amazon Linux 2 (Core), Amazon Linux 2023 et Amazon Linux 2027 Preview. Le suivi d'Ubuntu ne comportait aucune page pour cette CVE au moment de la vérification de la publication.
Pour les systèmes Red Hat, une simple comparaison de versions avec la version amont peut générer une alerte trompeuse. L'éditeur intègre les correctifs dans les versions de paquets existantes afin de préserver la compatibilité ; un scanner peut donc signaler à tort un paquet corrigé s'il ne vérifie que le numéro de version. Red Hat recommande un scanner certifié dans le cadre de son programme Vulnerability Scanner Certification.
Les administrateurs qui attendent une mise à jour peuvent désactiver HTTP/2. Selon The Hacker News, l'avis d'Apache ne fournit aucun contournement, mais Wiz recommande de retirer h2 et h2c des réglages Protocols concernés, en ne laissant que Protocols http/1.1. La même modification de configuration s'applique aux installations autonomes de mod_h2 concernées.
