Vulnérabilité critique de RCE corrigée dans Apache HTTP Server
La **Apache Software Foundation (ASF)** a publié des mises à jour de sécurité pour corriger une vulnérabilité critique d'exécution de code à distance (RCE) dans l'**Apache HTTP Server**. Identifiée sous la référence **CVE-2026-23918**, la faille provient d'un problème de double libération (double-free) dans la gestion du protocole HTTP/2.

### Double libération dans HTTP/2
La vulnérabilité, identifiée comme **CVE-2026-23918** (score CVSS : 8.8), est décrite comme une "double libération et possible RCE" dans la gestion du protocole HTTP/2. Elle affecte l'**Apache HTTP Server** 2.4.66 et a été corrigée dans la version 2.4.67.
**Bartlomiej Dmitruk**, co-fondateur de Striga.ai, et **Stanislaw Strzalkowski**, chercheur chez ISEC.pl, sont crédités de la découverte et du signalement de cette vulnérabilité.
### Détails techniques et exploitation
Selon Dmitruk, la gravité de **CVE-2026-23918** est critique, car elle peut être exploitée pour du déni de service (DoS) et du RCE. Il a détaillé les spécificités techniques :
> *CVE-2026-23918 est une double libération dans Apache httpd 2.4.66 `mod_http2`, spécifiquement dans le chemin de nettoyage des flux de h2_mplx.c. Le bug se déclenche lorsqu'un client envoie une trame HTTP/2 HEADERS immédiatement suivie d'une RST_STREAM avec un code d'erreur non nul sur le même flux, avant que le multiplexeur n'ait enregistré le flux.*
> *Deux callbacks nghttp2 sont alors appelés en séquence, on_frame_recv_cb pour le RST et on_stream_close_cb pour la fermeture, et tous deux finissent par appeler h2_mplx_c1_client_rst -> m_stream_cleanup, qui ajoute deux fois le même pointeur h2_stream au tableau de nettoyage (spurge cleanup array). Lorsque c1_purge_streams itère plus tard sur le tableau et appelle h2_stream_destroy -> apr_pool_destroy sur chaque entrée, le second appel touche une mémoire qui a déjà été libérée.*
Dmitruk a expliqué que l'attaque DoS est simple sur tout déploiement par défaut avec `mod_http2` et un MPM (**Multi-Processing Module**) multi-threadé. Le RCE, cependant, nécessite un **Apache Portable Runtime (APR)** avec l'allocateur mmap, ce qui est le cas par défaut sur les systèmes dérivés de Debian et sur l'image Docker officielle d'httpd.
### Chemin d'exploitation RCE
Dmitruk a détaillé davantage l'exploit RCE :
> *Le premier résultat est un déni de service, qui est trivial : une connexion TCP, deux trames, aucune authentification, aucun en-tête spécial, aucune URL spécifique, et le worker plante. Apache le relance, mais chaque requête sur le worker planté est ignorée, et le schéma peut être maintenu tant que l'attaquant continue d'envoyer.*
> *Le second résultat est l'exécution de code à distance, et nous avons construit une preuve de concept fonctionnelle sur x86_64. La chaîne place une fausse structure h2_stream à l'adresse virtuelle libérée via la réutilisation de mmap, pointe sa fonction de nettoyage de pool vers `system()`, et utilise la mémoire du scoreboard d'Apache comme conteneur stable pour les fausses structures et la chaîne de commande.*
> *Le scoreboard se trouve à une adresse fixe pendant toute la durée de vie du serveur, même avec ASLR, ce qui rend le chemin RCE pratique. Les mises en garde habituelles s'appliquent : l'exploitation pratique nécessite une fuite d'informations pour `system()` et les décalages du scoreboard, et le heap spray est probabiliste, mais dans des conditions de laboratoire, l'exécution se produit en quelques minutes.*
### Atténuation et recommandations
Dmitruk a précisé que le MPM prefork n'est pas affecté par la faille. Cependant, il a averti que la surface d'attaque est significative, car `mod_http2` est inclus dans les compilations par défaut et HTTP/2 est largement activé dans les environnements de production. Il est fortement recommandé aux utilisateurs d'appliquer les derniers correctifs pour atténuer le risque posé par cette vulnérabilité.