Apache HTTP/2 CVE-2026-23918 : la double-free qui menace vos serveurs web et vos conteneurs Docker

Le 4 mai 2026, l'Apache Software Foundation a publié la version 2.4.67 de son serveur HTTP, corrigeant cinq vulnérabilités. La plus sévère, CVE-2026-23918 (CVSS 8.8), est une double-free dans l'implémentation HTTP/2 qui permet un déni de service trivial et, dans certaines configurations, une exécution de code à distance sans authentification. Et le pire : elle touche les configurations par défaut de nombreuses distributions Debian et des images Docker officielles.

Apache httpd étant l'un des serveurs web les plus déployés au monde, et HTTP/2 étant activé par défaut, cette faille mérite qu'on s'y attarde — pas seulement pour patcher, mais pour comprendre pourquoi un bug de gestion mémoire vieux de plusieurs années n'est devenu exploitable que maintenant.

De quoi parle-t-on ? La double-free en deux mots

Une double-free (CWE-415) survient quand un programme libère deux fois la même zone de mémoire. Le second appel à free() opère sur un pointeur qui ne lui appartient plus : selon l'état de l'allocateur, cela provoque un crash (DoS) ou, si un attaquant maîtrise ce qui a été réalloué entre-temps, une corruption du tas exploitable pour détourner le flux d'exécution (RCE).

Ici, la zone doublement libérée est un objet de flux HTTP/2 (h2_stream), détruit deux fois lors du nettoyage des flux dans mod_http2.

La cause racine : un nettoyage de flux dédoublé

La vulnérabilité vit dans le chemin de nettoyage des flux, précisément dans h2_mplx.c. Le déclencheur est une question de timing dans l'ordre des frames HTTP/2 :

Le client envoie une frame HEADERS immédiatement suivie d'un RST_STREAM avec un code d'erreur non nul, sur le même flux, avant que le multiplexeur n'ait enregistré ce flux.

Deux callbacks de la bibliothèque nghttp2 se déclenchent alors en séquence :

• on_frame_recv_cb (pour le RST_STREAM)
• on_stream_close_cb (pour la fermeture du flux)

Les deux finissent par appeler h2_mplx_c1_client_rst → m_stream_cleanup, qui empile le même pointeur h2_stream deux fois dans le tableau de nettoyage spurge. Plus tard, c1_purge_streams parcourt ce tableau et appelle h2_stream_destroy → apr_pool_destroy sur chaque entrée. Le deuxième passage frappe une mémoire déjà libérée : double-free.

Le cœur du problème, c'est un suivi de propriété non synchronisé entre les callbacks de nettoyage HTTP/2 — exactement le genre de bug de concurrence que les serveurs multi-threadés rendent difficile à raisonner.

Pourquoi seulement maintenant ? L'effet d'un changement d'allocateur

Le détail le plus instructif : le bug latent existait probablement avant, mais il n'est devenu une double-free exploitable qu'avec la version 2.4.66, à cause d'un changement d'allocateur mémoire dans mod_http2 v2.0.33 livré avec cette release. C'est un rappel classique : une vulnérabilité de sécurité n'est pas qu'une ligne de code fautive, c'est aussi le contexte d'exécution qui la rend (ou non) déclenchable.

Êtes-vous vulnérable ? Les trois conditions

Trois prérequis doivent être réunis :

1. Apache HTTP Server 2.4.66 (la version où l'allocateur rend le bug exploitable).
2. HTTP/2 activé — c'est le cas par défaut dès que mod_http2 est chargé en 2.4.66.
3. Un MPM multi-threadé : worker ou event. Le MPM prefork (mono-thread) n'est pas affecté, le bug ne se manifestant pas dans ce modèle.

Vérification rapide :

# Version d'Apache (attention aux backports de distrib)
httpd -v        # RHEL/CentOS
apache2ctl -v   # Debian/Ubuntu

# mod_http2 chargé ?
apache2ctl -M 2>/dev/null | grep http2

# MPM en cours
apache2ctl -V 2>/dev/null | grep -i mpm

DoS trivial, RCE conditionnel : le vrai niveau de risque

Il faut distinguer les deux impacts :

• Déni de service — le chemin est trivial et ne demande aucune authentification : quelques frames bien ordonnées suffisent à crasher les processus worker. Une source rapporte une exploitation DoS déjà observée dans la nature.
• Exécution de code à distance — bien plus sophistiquée, mais prouvée viable par les découvreurs. Elle est facilitée sur les déploiements utilisant APR avec mmap — précisément la configuration des systèmes Debian et des images Docker officielles. Un PoC existe ; pas d'exploitation RCE massive publique constatée à ce jour.

Autrement dit : si vous tournez Apache 2.4.66 en conteneur Docker officiel, vous êtes dans le scénario le plus exposé. La faille a été découverte par Bartlomiej Dmitruk et Stanislaw Strzalkowski lors d'une revue de code interne, et rapportée le 10 décembre 2025.

Remédiation : patcher, ou mitiger en attendant

La seule remédiation complète est la mise à jour vers Apache 2.4.67+, qui supprime entièrement le chemin de nettoyage vulnérable.

Si vous ne pouvez pas patcher immédiatement, deux mitigations efficaces :

1. Désactiver mod_http2 : le code vulnérable n'est alors plus exécuté.

   # Debian/Ubuntu
   sudo a2dismod http2 && sudo systemctl restart apache2

2. Basculer sur le MPM prefork : le bug ne se manifeste pas dans ce modèle mono-thread (au prix de performances moindres).

Les distributions ont backporté le correctif — par exemple l'avis USN-8239-1 pour Ubuntu. Vérifiez votre gestionnaire de paquets plutôt que de vous fier au seul numéro de version upstream.

Détection : repérer une exploitation

Surveillez les signaux suivants :

• Crashs répétés des processus worker Apache (le symptôme principal du DoS).
• Entrées de log mentionnant double-free ou corruption de tas.
• Trafic HTTP/2 anormal : rafales de HEADERS suivies immédiatement de RST_STREAM.
• Core dumps liés à la gestion mémoire — à analyser.

Pour une détection runtime fine au niveau kernel (processus enfants anormaux, crashs), un outillage eBPF type Falco est idéal.

La leçon : HTTP/2, surface d'attaque récurrente

CVE-2026-23918 n'est pas un cas isolé. L'implémentation HTTP/2 — avec son multiplexage, ses flux concurrents et sa gestion d'état complexe — est devenue une source récurrente de vulnérabilités à travers tous les serveurs (rappelez-vous des familles « Rapid Reset » et consorts). La concurrence et la gestion mémoire manuelle en C forment un cocktail propice aux use-after-free et double-free.

Deux réflexes à ancrer : traiter tout serveur exposé comme un actif critique à patcher en priorité, et réduire la surface — n'activer HTTP/2 que si vous en avez l'usage, segmenter, et placer une couche de défense en amont. C'est la logique d'une architecture Zero Trust appliquée jusqu'à la couche web. Et si vous hésitez encore entre Apache et son concurrent, notre guide de configuration NGINX détaille une alternative robuste.