Apache corrige une faille permettant d’exécuter du code sans mot de passe dans la version 2.4.71

Si Apache sert votre site ou votre API en HTTP/2, votre équipe infrastructure a une tâche urgente : vérifier la version et installer le correctif. Une faille découverte dans le module chargé de ce protocole permet à un attaquant non authentifié d’obtenir l’exécution de code. Le serveur placé devant votre application peut ainsi être exposé : cette attaque ne nécessite aucun mot de passe d’administration.

Apache a publié un correctif le 11 novembre dans la version 2.4.71. La vulnérabilité, référencée CVE-2026-119618, a été classée critique. Selon l’avis officiel d’Apache, les versions 2.4.55–2.4.70 sont concernées. Voilà une raison très concrète de consulter l’inventaire des serveurs, de déterminer où HTTP/2 est utilisé et de désigner un responsable de la mise à jour.

Ce qui a dysfonctionné dans le serveur

La faille se situe dans mod_http2, au sein de la fonction assign_headers(). Plusieurs threads accèdent à des ressources partagées sans synchronisation adéquate. Le serveur peut alors corrompre sa propre mémoire, et un attaquant peut exploiter cette corruption pour exécuter du code.

Imaginez deux employés qui modifient simultanément une même ligne de commande. L’un en change le contenu tandis que l’autre continue de travailler à partir de son ancien état. Pour un serveur web, ce défaut de coordination est dangereux : il touche la mémoire d’un processus en cours d’exécution. Il s’agit d’une analogie simplifiée de la cause du problème, et non de la description d’une méthode d’attaque prête à l’emploi.

Prenons un cas concret : Apache placé devant un service d’abonnement. Même si l’accès à l’espace client est protégé par une authentification multifacteur, le traitement du protocole réseau intervient avant la vérification de l’utilisateur par l’application. Renforcer les mots de passe ne résout donc pas ce problème précis. L’équipe doit corriger le composant qui reçoit les requêtes.

Le rôle d’Anthropic et de Google

Apache cite parmi les auteurs de la découverte Anthropic OSS Scanner, ainsi qu’Anthony Weems et Simon Scannell, de Google Cloud Vulnerability Research. Le signalement d’Anthropic a été reçu le 26 octobre, celui de Google le 3 novembre. Ces informations confirment la participation du scanner d’Anthropic à la découverte d’une faille grave dans un logiciel serveur largement utilisé.

Mais dire que « l’IA a trouvé une faille » masque un détail essentiel : la notice officielle cite un scanner précis et des chercheurs identifiés. Elle ne permet pas de conclure que les deux découvertes sont entièrement autonomes, ni que l’intervention humaine n’est plus nécessaire pour vérifier les résultats. Pour les développeurs d’outils de sécurité, c’est le résultat lui-même qui retient l’attention : la recherche automatisée a permis de repérer un défaut de coordination entre threads susceptible de conduire à l’exécution de code.

Les chiffres sur l’ampleur de l’exposition doivent être lus avec précaution. Selon les données de Wiz, 64% des environnements cloud observés comportent des ressources utilisant des versions vulnérables, et 51% contiennent des instances accessibles publiquement. L’entreprise précise que ces estimations ne tiennent pas compte de la configuration. Le nombre d’installations ne révèle donc pas, à lui seul, combien de serveurs peuvent effectivement être attaqués via HTTP/2.

Au moment de la publication de Wiz, le 11 novembre, aucun exploit public ni aucun cas d’exploitation n’avait été signalé. Il s’agit d’un état des lieux à une date donnée : il ne garantit pas l’absence d’attaques et ne décrit pas la situation une semaine plus tard.

Ce que votre équipe doit vérifier

Commencez par les serveurs accessibles depuis Internet : identifiez la version d’Apache, la présence de mod_http2 et l’utilisation effective de HTTP/2. Si un autre proxy est placé devant l’application, déterminez quel protocole parvient jusqu’à Apache. La seule présence d’un service intermédiaire ne répond pas à cette question.

Installez ensuite le correctif Apache 2.4.71 ou la mise à jour de paquet adaptée fournie par le fournisseur de votre système. Pour les paquets intégrant des correctifs rétroportés, consultez l’avis du fournisseur : le numéro de version de base ne suffit pas toujours à savoir si le correctif est présent. Après la mise à jour, vérifiez le démarrage du serveur, la configuration et les principaux parcours utilisateur.

Si la mise à jour doit être reportée, Wiz propose de désactiver temporairement HTTP/2. Après ce changement, assurez-vous que le service reste accessible aux clients et que le protocole concerné est effectivement désactivé. Cette mesure est provisoire, en attendant l’installation du correctif.

Pour un responsable produit ou un fondateur, la tâche est très concrète : donner à l’équipe le temps de procéder à la mise à jour et obtenir une confirmation des serveurs vérifiés. Ce résultat est plus utile qu’un message général affirmant que « la sécurité est sous contrôle ».