Le projet Apache HTTP Server a publié la version 2.4.71 le 11 novembre ; elle corrige 3 vulnérabilités : 1 critique, 1 importante et 1 faible. La plus grave est CVE-2026-119618 : une situation de compétition dans assign_headers(), au sein du module HTTP/2 mod_http2, corrompt la mémoire du tas, et Apache indique qu'elle peut conduire à une exécution de code à distance. Elle touche les versions 2.4.55 à 2.4.70 (2.0.8 à 2.0.42 pour mod_h2, publié séparément). La base nationale américaine des vulnérabilités (NVD) a enregistré la CVE le 11 novembre et ne lui a pas encore attribué de score ; elle ne figure pas au catalogue KEV de la CISA et nous n'avons vu à ce jour aucun signalement d'exploitation. Les serveurs qui tournent sous nginx ne sont pas concernés.

Les trois failles

  • CVE-2026-119618 (critique) : l'exécution de code à distance dans mod_http2 décrite ci-dessus. D'après la fiche d'Apache, le projet d'analyse de logiciels open source d'Anthropic l'a signalée le 26 octobre, l'équipe Google Cloud Vulnerability Research l'a signalée indépendamment le 3 novembre, et le correctif a été livré avec la version 2.4.71 le 11 novembre.
  • CVE-2026-106023 (importante) : un déréférencement de pointeur NULL dans mod_md, pendant le traitement d'une requête, fait planter un processus enfant ; les versions 2.4.30 à 2.4.70 sont touchées. mod_md est le module d'Apache qui obtient et renouvelle automatiquement les certificats : la faille est donc sans importance si vous ne l'avez pas activé.
  • CVE-2026-109163 (faible) : un écrasement de 1 octet dans un tampon de pile de mod_vhost_alias, qui ne touche que les versions 2.4.69 et 2.4.70 ; c'est un reliquat du correctif de CVE-2026-63292 du 1er octobre.

Votre Apache est-il concerné ?

  • Vérifiez d'abord la version : apache2 -v sur Debian et Ubuntu, généralement httpd -v ailleurs. Exécutez ensuite apachectl -M | grep http2 pour voir si le module http2 est chargé ; l'absence de sortie signifie que HTTP/2 n'est pas activé.
  • Debian : au 12 novembre, tous les paquets de 2.4.67 à 2.4.69 dans Debian 12 et 13 sont marqués vulnérables, et seule unstable a une version corrigée définie, 2.4.71-1.
  • Ubuntu : l'avis USN-9016-1 du 10 novembre a corrigé la série de failles précédente (celle de la 2.4.69), avec pour versions corrigées 2.4.52-1ubuntu4.26 sur 22.04, 2.4.58-1ubuntu8.18 sur 24.04 et 2.4.66-2ubuntu2.7 sur 26.04, et il n'inclut pas CVE-2026-119618. D'après la plage indiquée par Apache, la 2.4.58 de 24.04 et la 2.4.66 de 26.04 font partie des versions touchées, mais pas la 2.4.52 de 22.04 ; au moment où nous écrivions, nous n'avions pas trouvé l'évaluation d'Ubuntu lui-même pour cette CVE : fiez-vous donc à sa page de sécurité.

Ce que vous pouvez faire avant l'arrivée du correctif

L'avis d'Apache ne mentionne aucune mesure d'atténuation temporaire et recommande simplement de passer à la version 2.4.71. Le code vulnérable se trouve dans mod_http2, et les requêtes ne l'atteignent jamais lorsque le module n'est pas chargé. En attendant que votre distribution livre le correctif, une option prudente consiste donc à désactiver HTTP/2 : sur Debian et Ubuntu, exécutez sudo a2dismod http2 && sudo systemctl restart apache2. Le site se replie sur HTTP/1.1 et continue de fonctionner, même si les pages comportant de nombreuses ressources se chargeront un peu plus lentement. Après avoir installé le paquet corrigé, réactivez le module avec sudo a2enmod http2 et redémarrez. Si vous avez compilé Apache vous-même ou l'avez installé au moyen d'un panneau de contrôle, vous devez passer vous-même à la version 2.4.71 ou attendre le dépôt du panneau ; les réglages de sécurité du panneau sont décrits dans notre guide d'installation et de sécurisation d'aaPanel.

C'est la deuxième fois en un mois qu'un grand serveur web est touché par une faille grave ; la précédente fois, il s'agissait des 5 failles corrigées par nginx le 14 octobre. La faille de mod_md touche au renouvellement automatique des certificats, et la mise en place des certificats est expliquée dans notre tutoriel pour configurer un certificat SSL Let's Encrypt. Si le serveur a présenté des processus inhabituels ou des fichiers inconnus pendant cette période, suivez notre guide d'enquête et de re-sécurisation d'un VPS compromis.