Apache HTTP Server est l’un des serveurs web les plus répandus sur Internet et constitue la base d’une part significative des services web, des sites les plus simples aux backends applicatifs complexes. Ses performances et sa stabilité sont essentielles à la continuité opérationnelle, faisant de sa sécurité une priorité absolue pour les administrateurs système et les équipes de sécurité du monde entier.

Cette vulnérabilité représente un risque élevé car elle permet à un utilisateur distant non authentifié de provoquer un Déni de Service (DoS) complet avec un effort minimal. L’attaque ne nécessite aucun privilège spécial ni interaction de l’utilisateur. Des codes d’exploitation publics sont disponibles et l’attaque est simple à exécuter, ce qui augmente considérablement la probabilité d’exploitation.

Toute instance d’Apache HTTP Server exposée à Internet exécutant une version vulnérable avec le protocole HTTP/2 activé est à risque. Une attaque réussie rendra indisponibles tous les services web hébergés, entraînant une interruption opérationnelle, des pertes économiques potentielles et des dommages réputationnels. Compte tenu de l’utilisation étendue du serveur, l’impact potentiel est considérable.

Produit	Apache HTTP Server
Date	06/12/2025 12:33:40

Résumé technique

La cause technique de la vulnérabilité est une gestion inappropriée du mécanisme de contrôle de flux HTTP/2, classée sous le nom de CWE-400 : Consommation incontrôlée de ressources. Il s’agit d’une variante de l’attaque “slow loris”, spécifiquement dirigée vers l’implémentation du protocole HTTP/2 du serveur.

L’attaque se déroule comme suit :

1. L’attaquant initie une connexion HTTP/2 vers une instance vulnérable d’Apache HTTP Server.
2. L’attaquant envoie ensuite une trame SETTINGS avec le paramètre SETTINGS_INITIAL_WINDOW_SIZE réglé sur 0.
3. Ce paramètre malveillant induit la logique de gestion des connexions du serveur à se bloquer indéfiniment lors du traitement des données suivantes provenant du client, en attendant une mise à jour de la fenêtre qui n’arrivera jamais.
4. Chacune de ces connexions bloquées occupe un thread worker. En initiant plusieurs connexions similaires, un attaquant peut rapidement épuiser tous les threads worker disponibles sur le serveur.
5. Une fois le pool de threads worker épuisé, le serveur n’est plus en mesure d’accepter de nouvelles connexions, refusant ainsi efficacement le service aux utilisateurs légitimes.

Conceptuellement, la configuration client malveillante ressemblerait à ceci :

# Représentation conceptuelle d'une trame SETTINGS HTTP/2 malveillante
# Ne pas utiliser comme chaîne d'attaque.
SETTINGS {
    SETTINGS_INITIAL_WINDOW_SIZE = 0
}

• Versions impactées : Apache HTTP Server 2.4.55 à 2.4.57
• Version corrigée : Apache HTTP Server 2.4.58

Recommandations

• Appliquer le correctif immédiatement : Mettre à jour les instances d’Apache HTTP Server vers la version corrigée 2.4.58 ou ultérieure. C’est le moyen le plus efficace de corriger la vulnérabilité.

• Atténuations :

• En mesure temporaire jusqu’à l’application du correctif, envisagez de désactiver le protocole HTTP/2 s’il n’est pas essentiel à l’environnement. Cela peut être fait en modifiant la directive Protocols dans la configuration d’Apache (ex. Protocols http/1.1).

• Utiliser un pare-feu d’application web (WAF) ou un dispositif périmétrique capable d’inspecter et de normaliser le trafic HTTP/2 pour bloquer les requêtes avec une taille de fenêtre initiale égale à zéro.

• Chasse & Surveillance :

• Surveiller la page server-status d’Apache pour détecter un nombre anormal de connexions bloquées en état “Read” ou “Write” persistant sans transfert de données.

• Analyser le trafic réseau pour détecter une augmentation soudaine des connexions HTTP/2, en particulier celles qui se bloquent après l’échange initial de la trame SETTINGS.

• Configurer des alertes pour une utilisation élevée et continue des threads worker, ce qui peut constituer un indicateur précoce de l’attaque.

• Réponse aux incidents :

• En cas de suspicion de compromission, redémarrer proprement le service Apache pour terminer toutes les connexions existantes et libérer le pool de threads worker.

• Bloquer temporairement les adresses IP sources responsables de l’attaque au niveau du pare-feu. Notez que les attaquants peuvent facilement changer d’adresse IP, rendant cette mesure uniquement temporaire.

• Donner la priorité au déploiement immédiat du correctif (version 2.4.58) pour prévenir toute récidive.

• Défense en profondeur :

• Implémenter des politiques de limitation des connexions et du trafic sur les dispositifs périmétriques pour ralentir les attaques par épuisement des ressources.

• S’assurer que des systèmes de surveillance et de journalisation complets du serveur sont actifs pour fournir une visibilité sur les états de connexion et l’utilisation des ressources.

[Callforaction-THREAT-Footer]