CVE-2026-23918 : RCE Apache HTTP/2 double-free (CVSS 8.8)

Les faits

L'Apache Software Foundation a publié le 4 mai 2026 la version 2.4.67 d'Apache HTTP Server, accompagnée d'un advisory traitant cinq vulnérabilités, dont la plus critique – CVE-2026-23918 – est une corruption mémoire de type double-free dans le module mod_http2. Avec un score CVSS v3.1 de 8.8 (vecteur AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), cette faille est exploitable à distance, sans interaction utilisateur, depuis le réseau, et produit un impact maximal sur la confidentialité, l'intégrité et la disponibilité du service. Le scénario le plus probable se traduit par un déni de service immédiat (crash du worker httpd) et, dans des conditions favorables d'alignement mémoire, par une exécution de code arbitraire dans le contexte du processus httpd.

Le bug est référencé CWE-415 (double-free) et se loge dans le chemin de nettoyage des flux HTTP/2 du fichier h2_mplx.c, plus précisément dans la logique du multiplexer qui gère le cycle de vie des streams. La condition de déclenchement décrite par les chercheurs est très spécifique : un client envoie une trame HEADERS HTTP/2 immédiatement suivie d'une trame RST_STREAM portant un code d'erreur non nul, le tout sur le même identifiant de stream et avant que le multiplexer n'ait formellement enregistré ce stream dans sa table interne. Dans cette fenêtre de course, le code de cleanup libère deux fois le même bloc heap. Sur les versions modernes de glibc et de jemalloc, un double-free corrompt les chaînes de tcache ou de bins libres, ouvrant la voie classique à des primitives d'écriture arbitraire et donc, en chaînant un leak d'adresse, à un détournement du flot d'exécution.

La vulnérabilité a été signalée à l'équipe de sécurité Apache le 10 décembre 2025 par Bartlomiej Dmitruk de striga.ai et Stanislaw Strzalkowski d'isec.pl, via le programme coordonné de divulgation de l'ASF. Un correctif a été poussé dans le tronc le lendemain (révision r1930444 du 11 décembre 2025), mais les mainteneurs ont préféré attendre la fenêtre de release planifiée pour publier 2.4.67 le 4 mai 2026, avec un communiqué public coordonné. Cinq mois se sont donc écoulés entre la disponibilité du fix dans le code source et sa diffusion publique – une période durant laquelle un attaquant compétent surveillant les commits Apache pouvait théoriquement reconstruire l'exploit en analysant la nature du correctif.

Le périmètre exact des versions vulnérables mérite attention. L'advisory officiel cible Apache HTTP Server 2.4.66 comme étant la branche directement exposée. Cependant, mod_http2 est compilé par défaut dans la majorité des distributions et activé dès qu'une directive Protocols inclut « h2 » ou « h2c ». Cela concerne pratiquement toutes les configurations TLS modernes utilisant ALPN pour négocier HTTP/2, y compris les architectures derrière des reverse proxies qui terminent eux-mêmes en HTTP/1.1 mais relayent HTTP/2 au backend. Les builds Linux Debian, Ubuntu, RHEL, Rocky, AlmaLinux et openSUSE qui livrent encore 2.4.66 ou ses dérivés sont à patcher en urgence dès la publication du paquet aval.

Au plan technique, le double-free dans h2_mplx.c découle d'un défaut de synchronisation entre deux paths de gestion d'erreur. Lorsqu'un stream est créé par une trame HEADERS, mod_http2 alloue une structure h2_stream et l'enregistre via h2_mplx_m_register_stream. Si une trame RST_STREAM arrive avant cette inscription complète, deux fonctions de nettoyage – le handler RST et le cleanup de fin de session – peuvent toutes deux invoquer apr_pool_destroy ou h2_stream_destroy sur la même structure, sans que le pointeur soit invalidé entre les deux passages. Le résultat : free() est appelé deux fois sur le même bloc, ce qui constitue le primitif de base pour une exploitation heap.

À ce jour (5 mai 2026), aucune exploitation in-the-wild n'a été confirmée publiquement par les CERT nationaux ni par CISA. Cependant, l'historique d'Apache montre que les vulnérabilités HTTP/2 attirent rapidement les chercheurs offensifs : CVE-2023-25690 (smuggling) et CVE-2024-38476 (mod_rewrite) avaient toutes deux vu apparaître des PoCs publics sous 72 heures. Plusieurs équipes de threat intelligence (notamment Hadrian, GreyNoise et Censys) ont d'ores et déjà annoncé la mise en place de signatures de détection, et un PoC fonctionnel circulera vraisemblablement avant la fin mai 2026.

Les autres vulnérabilités corrigées en parallèle dans 2.4.67 méritent également d'être évaluées : CVE-2026-29168 (DoS via mod_md / OCSP), CVE-2026-29169 (NULL pointer dereference dans mod_dav_lock), CVE-2026-24072 (lecture de fichiers arbitraires via .htaccess malicieux dans mod_rewrite – impact significatif en hébergement mutualisé) et CVE-2026-28780 (heap buffer overflow dans mod_proxy_ajp). Sur des plateformes d'hébergement partagé, CVE-2026-24072 peut être tout aussi critique que la RCE HTTP/2, puisqu'elle permet à un locataire de lire les configurations et secrets d'autres locataires.

Selon les données de Censys, plus de 35 millions de serveurs Apache HTTP Server sont exposés sur Internet, dont environ 60 % négocient HTTP/2 au moins en option. La surface d'attaque potentielle est donc colossale, particulièrement pour les sites e-commerce, les API publiques et les frontaux corporate qui privilégient HTTP/2 pour ses gains de performance.

Impact et exposition

Toute organisation exploitant Apache HTTP Server 2.4.66 (ou des builds antérieures partageant la même routine mod_http2) avec HTTP/2 activé est exposée. Les conditions d'exploitation sont très favorables à l'attaquant : pas d'authentification requise (PR:L correspond aux privilèges minimaux de la session HTTP elle-même, pas à un compte applicatif), pas d'interaction utilisateur, vecteur exclusivement réseau. Une simple session TLS établie avec négociation ALPN « h2 » suffit à atteindre le code vulnérable.

Le scénario le plus probable à court terme reste le déni de service : un attaquant peut faire planter de manière déterministe les workers httpd, provoquant des reboots de service et des pics de latence. Les architectures à processus pre-fork (MPM prefork) sont particulièrement sensibles, car chaque crash élimine un worker entier. La conversion vers une RCE complète demandera un travail d'exploitation plus poussé pour bypasser ASLR et stack canaries, mais l'écosystème de techniques modernes (House of Botcake, tcache poisoning) rend ce travail accessible aux attaquants avancés sous quelques semaines.

L'exposition est massive dans les secteurs suivants : hébergeurs mutualisés (cPanel, Plesk, DirectAdmin), plateformes SaaS construites sur des stacks LAMP, frontaux Apache devant des reverse-proxies (Varnish, HAProxy) qui terminent HTTP/2 côté client. Les CDN (Cloudflare, Fastly, Akamai) qui terminent eux-mêmes TLS sont moins exposés en frontal, mais leurs origines Apache restent vulnérables si elles parlent HTTP/2 en interne. Les administrateurs doivent considérer que toute interface Apache joignable depuis un réseau non maîtrisé est dans le périmètre de risque immédiat.

Côté détection, le trafic exploitant CVE-2026-23918 se caractérise par une cadence anormale de paires HEADERS/RST_STREAM sur des stream_id décroissants ou non séquentiels, avec des codes d'erreur RST inhabituels (NO_ERROR=0 est légitime, PROTOCOL_ERROR=1 ou INTERNAL_ERROR=2 dans ce schéma sont suspects). Les solutions WAF capables d'inspection HTTP/2 (Cloudflare WAF, Akamai Kona, AWS WAF v2 avec moteur HTTP/2) peuvent fournir des règles temporaires en attendant le patch.

Recommandations immédiates

• Mettre à jour Apache HTTP Server vers la version 2.4.67 (release du 4 mai 2026) sur tous les serveurs exposés — Apache Security Advisory du 4 mai 2026.
• Si la mise à jour ne peut être déployée immédiatement, désactiver HTTP/2 en éditant la directive Protocols dans httpd.conf : remplacer « Protocols h2 h2c http/1.1 » par « Protocols http/1.1 », puis recharger le service via systemctl reload httpd ou apachectl graceful.
• Sur les distributions Linux, surveiller la disponibilité des paquets backportés : apache2 sur Debian/Ubuntu (security tracker), httpd sur RHEL/Rocky/AlmaLinux (Red Hat Security Advisories), apache2 sur openSUSE/SLES.
• Activer la journalisation détaillée HTTP/2 (LogLevel http2:debug) en environnement de staging pour détecter les patterns d'exploitation, en restant attentif au volume de logs généré.
• Déployer des règles WAF temporaires bloquant les séquences HEADERS+RST_STREAM rapides avec codes d'erreur non standard sur le même stream_id.
• Auditer les autres correctifs de 2.4.67 : CVE-2026-24072 (mod_rewrite, lecture de fichiers via .htaccess) est particulièrement critique pour les hébergeurs mutualisés.
• Vérifier les builds custom et conteneurs Docker : les images apache:2.4.66, php:8.x-apache et httpd:2.4 doivent être rebâties à partir du tag 2.4.67.