Suivre Apache a publié une mise à jour de sécurité urgente concernant CVE-2026-119618, une vulnérabilité critique d’exécution de code à distance dans le module mod_http2 du serveur HTTP Apache. La faille affecte les versions 2.4.55 à 2.4.70 du serveur HTTP Apache et peut permettre à un attaquant distant non authentifié de corrompre la mémoire du tas et potentiellement d’exécuter des commandes arbitraires sur des serveurs vulnérables.
La vulnérabilité provient d’une synchronisation incorrecte lorsque Apache traite des requêtes HTTP/2 simultanées. Plusieurs threads peuvent accéder à des ressources partagées sans coordination suffisante, créant une condition de course qui permet à un thread de modifier la mémoire utilisée par un autre. Une exploitation réussie peut corrompre le tas interne du serveur et finalement conduire à une exécution de code à distance.
Seuls les déploiements Apache avec HTTP/2 activé sont exposés au chemin d’attaque connu. Les serveurs configurés exclusivement pour HTTP/1.1 n’atteignent pas la fonctionnalité vulnérable mod_http2. HTTP/2 peut être activé en utilisant h2 pour les connexions TLS ou h2c pour le HTTP/2 en clair via la directive de protocoles d’Apache.
Apache a corrigé la vulnérabilité dans HTTP Server 2.4.71, publié le 11 novembre 2026. Les versions autonomes de mod_h2 de GitHub, des versions 2.0.8 à 2.0.42, sont également affectées. L’avis officiel d’Apache n’identifie actuellement pas de version autonome corrigée de mod_h2 publiée séparément.
Red Hat a attribué à la vulnérabilité un score CVSS 3.1 de 9,8 pour son évaluation générale, avec une exploitation accessible sur le réseau, de faible complexité, ne nécessitant ni authentification, ni interaction utilisateur. Red Hat indique également que des recherches ont démontré une exploitation fiable contre un serveur configuré par défaut avec mod_http2 activé.
Cependant, au 12 novembre 2026, ni Apache ni les rapports de sécurité examinés ne documentent une exploitation dans des attaques réelles. Wiz n’a également signalé aucune exploitation connue dans la nature au moment de la publication. Les organisations devraient néanmoins donner la priorité à la remédiation car la vulnérabilité est accessible à distance et sa cause technique de base est maintenant publique.
Les organisations peuvent renforcer les défenses contre l’exploitation émergente avec la plateforme d’intelligence de détection IA native de SOC Prime, permettant aux équipes de sécurité d’opérationnaliser le renseignement sur les menaces et d’accélérer l’ingénierie de détection et la chasse aux menaces dans les environnements SIEM, EDR, XDR et Data Lake.
Détectez CVE-2026-119618 en identifiant les serveurs Apache face à Internet vulnérables avec HTTP/2 activé et en corrélant une activité HTTP/2 suspecte avec des pannes de serveurs Apache, des processus enfants anormaux, une exécution de commande inattendue, des fichiers nouvellement créés, et des connexions réseau sortantes inhabituelles.
Le contenu de détection peut ne pas être disponible pour chaque CVE. Vérifiez la Plateforme SOC Prime pour la couverture actuelle. Si les détections pertinentes ne sont pas encore disponibles, vérifiez à nouveau car de nouveaux renseignements sur les menaces et contenus de détection sont continuellement ajoutés.
Analyse CVE-2026-119618
CVE-2026-119618 affecte les versions 2.4.55 à 2.4.70 du serveur HTTP Apache lorsque la fonctionnalité vulnérable mod_http2 est présente et que HTTP/2 est activé. Le projet autonome mod_h2 est affecté des versions 2.0.8 à 2.0.42. Apache classe le problème comme critique et le mappe à CWE-362, Exécution Concurrente utilisant des Ressources Partagées avec Synchronisation Incorrecte.
La vulnérabilité existe dans la fonction assign_headers() utilisée par le traitement HTTP/2 d’Apache.
HTTP/2 diffère significativement de HTTP/1.1 car plusieurs flux peuvent fonctionner simultanément sur une seule connexion. Le module mod_http2 d’Apache utilise donc plusieurs threads pour traiter les requêtes et gérer les flux HTTP/2 simultanément.
Le problème se produit lorsque ces threads interagissent avec la mémoire partagée sans synchronisation suffisante. Selon l’évaluation technique de Red Hat, un travailleur de flux HTTP/2 peut écrire dans la mémoire appartenant au thread de connexion via un allocateur partagé sans verrou.
Dans le cadre d’un contrôle temporel par un attaquant, un accès concurrent peut corrompre le tas.
Les vulnérabilités de corruption de tas peuvent avoir différents résultats en fonction de la disposition de la mémoire et du contrôle de l’attaquant. Une exploitation échouée peut causer des pannes de processus de travail Apache, tandis qu’une corruption suffisamment contrôlée peut modifier l’état du programme ou rediriger l’exécution.
Red Hat déclare qu’une exploitation réussie peut permettre à un attaquant non authentifié d’exécuter des commandes arbitraires avec les privilèges du processus Apache HTTP Server. Cela peut donner aux attaquants accès aux données d’application, aux fichiers de configuration, aux identifiants disponibles pour le serveur Web, et à d’autres ressources accessibles dans ce contexte de sécurité.
La vulnérabilité est particulièrement préoccupante sur les systèmes face à Internet car aucun compte valide, mot de passe, clé API ou autre authentification n’est requise. Un attaquant a seulement besoin d’un accès réseau à un point de terminaison HTTP/2 affecté.
L’exposition dépend néanmoins de la configuration.
Apache HTTP Server doit effectivement offrir HTTP/2. Les administrateurs peuvent l’activer via la directive Protocols en utilisant :
Protocols h2 http/1.1
pour HTTP/2 sur TLS, ou :
Protocols h2c http/1.1
là où HTTP/2 en clair est pris en charge.
La directive peut être configurée globalement ou sur des hôtes virtuels individuels, ce qui signifie que les administrateurs doivent inspecter à la fois les configurations serveur et celles par site lors de l’évaluation de l’exposition.
Un serveur qui exécute une version affectée d’Apache mais ne sert que HTTP/1.1 n’est pas vulnérable en raison de cette faille. Red Hat confirme spécifiquement que les systèmes sans HTTP/2 activé n’atteignent pas le chemin de code affecté.
La gamme affectée en amont d’Apache ne devrait pas non plus être appliquée aveuglément aux paquets de distribution Linux.
Red Hat Enterprise Linux 8 et les versions antérieures ne contiennent pas le code vulnérable et ne sont pas affectées. RHEL 9 et RHEL 10 incluent des paquets mod_http2 affectés, mais Red Hat évalue le problème comme Important plutôt que Critique sur ces plateformes.
La différence vient des détails de l’implémentation. Sur RHEL 9 et 10, chaque flux HTTP/2 reçoit un allocateur de mémoire séparé plutôt que de partager le même allocateur avec la connexion. Red Hat indique que cette architecture augmente considérablement la complexité de l’exploitation, bien que les systèmes affectés nécessitent toujours des mises à jour de sécurité.
Red Hat a publié des paquets corrigés pour plusieurs flux RHEL 9 et RHEL 10 le 11 novembre. Les administrateurs utilisant des paquets Linux maintenus par le fournisseur devraient appliquer la mise à jour de sécurité de leur distribution au lieu de déterminer la vulnérabilité uniquement à partir de la version Apache amont affichée par le serveur.
Apache HTTP Server 2.4.71 fournit la correction en amont. Le correctif modifie le comportement de synchronisation et de gestion de mémoire vulnérable afin que les opérations HTTP/2 simultanées ne puissent pas interagir avec les ressources partagées affectées de manière non sécurisée.
La vulnérabilité a été découverte indépendamment grâce à deux efforts de recherche.
Le scanner OSS d’Anthropic a signalé le problème à l’équipe de sécurité d’Apache le 26 octobre 2026 sous l’identifiant ANT-2026-MAPKT6MZ. Anthony Weems et Simon Scannell de Google Cloud Vulnerability Research ont signalé indépendamment la vulnérabilité le 3 novembre. Apache a publié le correctif le 11 novembre.
L’enregistrement CVE a été publié le 11 novembre 2026.
La situation du PoC CVE-2026-119618 nécessite une interprétation prudente. Red Hat indique que la recherche publique a démontré un exploit fiable contre un serveur configuré par défaut avec mod_http2 activé. Cependant, The Hacker News et Wiz ont rapporté qu’aucun exploit RCE public disponible n’avait été identifié lors de la publication de leurs rapports. Les projets GitHub publics prétendant être des scanners ou des outils liés à l’exploitation ne devraient donc pas être interprétés automatiquement comme des codes RCE validés et convertis en arme.
Cette distinction est importante d’un point de vue opérationnel. Les défenseurs devraient supposer que la faille est techniquement exploitable tout en évitant les affirmations selon lesquelles un exploit converti en arme fiable circule déjà largement, à moins que d’autres preuves n’émergent.
Pour la détection de CVE-2026-119618, les équipes de sécurité devraient d’abord identifier les systèmes exposés plutôt que de se fier uniquement aux signatures d’exploit.
Les administrateurs peuvent confirmer si le module HTTP/2 est chargé en utilisant :
apachectl -M | grep http2
Ils devraient ensuite inspecter les fichiers de configuration Apache pour les directives Protocols contenant h2 ou h2c, y compris les directives définies dans des hôtes virtuels individuels.
La découverte de services externes peut également identifier des serveurs négociant HTTP/2 par le biais de TLS ALPN. Cependant, l’identification de version seule peut être trompeuse car les distributions Linux rétroportent fréquemment les correctifs de vulnérabilité sans changer la chaîne de version ressemblant à celle de l’amont.
La télémétrie d’exécution devrait être corrélée avec le trafic HTTP/2 suspect. Les indicateurs potentiels incluent des plantages répétés des travailleurs Apache, des fautes de segmentation, des redémarrages anormaux, des messages de corruption de mémoire, ou une instabilité soudaine du service associée à des rafales de requêtes HTTP/2 inhabituelles.
Parce qu’une exploitation réussie peut fournir une exécution de commandes, la télémétrie des points de terminaison et des hôtes devrait également être examinée pour des processus enfants inhabituels provenant d’Apache.
Les exemples incluent httpd ou apache2 lançant de manière inattendue des shells, des interpréteurs de script, des utilitaires de téléchargement, ou des commandes d’administration système.
Les équipes de sécurité devraient examiner les relations de processus telles que :
httpd → /bin/sh
apache2 → bash
httpd → curl
apache2 → wget
ou d’autres chaînes d’exécution inconsistantes avec le comportement normal de l’application hébergée.
La création de fichiers dans des répertoires temporaires, des racines Web, des emplacements de démarrage, ou des dossiers d’application modifiables peut également indiquer une activité post-exploitation. Les connexions sortantes inattendues des processus de travail Apache devraient recevoir une vigilance similaire.
Il n’existe actuellement aucun IOC publié par les fournisseurs spécifiques à une campagne pour CVE-2026-119618, tels que des adresses IP malveillantes, des domaines, des hachages de charges utiles, ou une infrastructure d’attaquant car Apache et les sources examinées n’ont pas signalé d’exploitation dans la nature. Cela rend l’évaluation de la configuration et la surveillance basée sur le comportement plus précieuses que le traçage d’indicateurs statiques.
Atténuation de CVE-2026-119618
La principale remédiation est de mettre à jour les installations affectées du serveur HTTP Apache vers la version 2.4.71 ou d’appliquer le paquet de sécurité corrigé fourni par le vendeur du système d’exploitation. Apache 2.4.71 a été publié le 11 novembre 2026 et contient le correctif amont.
Les organisations devraient donner la priorité aux déploiements Apache face à Internet avec HTTP/2 activé car ces systèmes exposent directement la fonctionnalité vulnérable au trafic réseau non fiable.
Les administrateurs doivent prendre les étapes suivantes :
- Inventorier les déploiements de serveur HTTP Apache à travers les environnements de production, de développement, en nuage, et de conteneurs.
- Identifier les installations exécutant Apache 2.4.55 à 2.4.70.
- Vérifier si mod_http2 est chargé.
- Inspecter les directives Protocols globales et d’hôte virtuel pour h2 ou h2c.
- Mettre à niveau les déploiements Apache en amont vers la version 2.4.71 ou ultérieure.
- Appliquer les paquets spécifiques à la distribution lorsque Apache est géré par Debian, Red Hat, Amazon Linux, ou un autre fournisseur de système d’exploitation.
- Redémarrer Apache après le patching pour s’assurer que les processus de travail vulnérables ne fonctionnent plus.
- Vérifier la configuration effective du serveur HTTP après la remédiation.
- Examiner la télémétrie historique pour une activité suspecte sur les systèmes face à Internet qui étaient exposés avant le patching.
Les administrateurs ne devraient pas supposer que l’installation d’un paquet de système d’exploitation avec un numéro de version inférieur à 2.4.71 signifie que le système reste vulnérable. Les vendeurs tels que Red Hat rétroportent des correctifs de sécurité dans leurs propres versions de paquets, donc l’avis de distribution pertinent doit être considéré comme faisant autorité.
L’avis officiel d’Apache ne fournit pas de solution de contournement. Cependant, les organisations qui ne peuvent pas patcher immédiatement peuvent temporairement retirer HTTP/2 des configurations exposées, éliminant l’accès au chemin de code vulnérable connu. Wiz recommande de restreindre le serveur à HTTP/1.1 jusqu’à ce que la mise à jour puisse être déployée.
Par exemple :
Protocols http/1.1
Les organisations appliquant ce contournement devraient inspecter tous les hôtes virtuels car une configuration spécifique à un site peut activer indépendamment h2 ou h2c.
La suppression de HTTP/2 peut affecter la performance de l’application et le comportement du client, donc le changement devrait être testé et traité comme une mesure temporaire de réduction des risques plutôt qu’un remplacement pour l’installation de la mise à jour de sécurité.
La stratégie d’atténuation de CVE-2026-119618 devrait également inclure la réduction de l’exposition inutile. Les services Apache administratifs ou internes qui n’ont pas besoin de connectivité directe à Internet devraient être restreints par segmentation réseau, équilibreur de charge, proxys inversés, politiques de firewall, ou adresses privées.
Les organisations utilisant des versions autonomes mod_h2 entre 2.0.8 et 2.0.42 nécessitent une attention particulière. Apache identifie ces versions comme étant affectées, tandis que The Hacker News a rapporté qu’aucune version autonome corrigée n’avait été publiée au moment de son rapport du 12 novembre. Désactiver HTTP/2 ou migrer vers un paquet du serveur HTTP Apache contenant le correctif en amont peut donc être nécessaire jusqu’à ce qu’une mise à jour autonome appropriée soit disponible.
Si une activité suspecte est découverte, les défenseurs devraient isoler le serveur affecté là où il est opérationnellement faisable et conserver les journaux d’accès Apache, les journaux d’erreurs, les journaux système, la télémétrie des processus, les connexions réseau, et les informations de mémoire ou de crash pertinentes.
Une exploitation réussie devrait être traitée comme un compromis potentiel du serveur plutôt que simplement un plantage de service. Les enquêteurs devraient rechercher de nouveaux fichiers, des shells Web, du code d’application altéré, des mécanismes de persistance, des identifiants volés, un trafic sortant suspect, et des preuves de mouvement latéral.
Les identifiants accessibles au processus Apache, y compris les mots de passe de base de données, les clés API, les identifiants de cloud, les clés privées TLS, ou les secrets stockés dans la configuration de l’application, devraient être examinés et rotés lorsque les preuves suggèrent qu’une exécution de code contrôlée par l’attaquant s’est produite.
FAQ
Qu’est-ce que CVE-2026-119618 et comment fonctionne-t-il ?
CVE-2026-119618 est une condition de course critique dans le module mod_http2 du serveur HTTP Apache. Le traitement HTTP/2 simultané peut amener plusieurs threads à accéder à la mémoire partagée sans synchronisation appropriée, entraînant une corruption du tas. Un attaquant distant non authentifié qui peut atteindre un service HTTP/2 affecté peut être capable de manipuler cette corruption et d’exécuter du code arbitraire avec les privilèges du processus serveur Apache.
Quand CVE-2026-119618 a-t-il été découvert pour la première fois ?
Le scanner OSS d’Anthropic a signalé la faille à Apache le 26 octobre 2026. Anthony Weems et Simon Scannell de Google Cloud Vulnerability Research l’ont indépendamment signalée le 3 novembre. Apache a divulgué publiquement la vulnérabilité et a publié Apache HTTP Server 2.4.71 contenant le correctif le 11 novembre 2026.
Quel est l’impact de CVE-2026-119618 sur les systèmes ?
Une exploitation réussie peut corrompre le tas d’Apache et conduire à une exécution de code à distance non authentifiée. Un attaquant peut exécuter des commandes en utilisant les privilèges du processus Apache, potentiellement accéder à des données d’application sensibles, modifier des fichiers, établir une persistance, perturber des services ou utiliser le serveur compromis comme point d’entrée pour des attaques supplémentaires. Red Hat attribue à la faille un score CVSS 3.1 générique de 9,8.
CVE-2026-119618 peut-il encore m’affecter en 2026 ?
Oui. Les versions 2.4.55 à 2.4.70 du serveur HTTP Apache restent vulnérables lorsque mod_http2 et HTTP/2 sont activés, à moins que le fournisseur du système d’exploitation n’ait rétroporté le correctif. Au 12 novembre 2026, les sources examinées ne signalent pas d’exploitation confirmée dans la nature, mais une exploitation fiable a été démontrée dans la recherche en sécurité.
Comment puis-je me protéger contre CVE-2026-119618 ?
Mettre à niveau le serveur HTTP Apache en amont vers la version 2.4.71 ou ultérieure, ou installer le paquet corrigé fourni par votre distribution Linux. Si un patch immédiat est impossible, désactivez temporairement HTTP/2 en supprimant h2 et h2c de la configuration Protocols et en restreignant l’accès externe inutile. Les équipes de sécurité devraient surveiller l’avis d’Apache et les suivis de sécurité des distributions pour des détails mis à jour pour CVE-2026-119618 à mesure que de nouvelles recherches sur les exploits et des informations de remédiation deviennent disponibles.
