Ubuntu Server installe encore Nginx 1.28 dans ses dépôts officiels, une version vulnérable à la faille HTTP/2 Bomb (CVE-2026-49975) capable d’épuiser la mémoire d’un serveur en quelques secondes avec une seule connexion. Ce tutoriel détaille, à partir d’un cas réel rencontré sur Apollo, comment auditer les modules NginX existants, basculer proprement sur le dépôt officiel NginX mainline avec APT, puis valider et nettoyer l’installation.
Le symptôme : un serveur qui tombe sans raison apparente
En ce début de semaine, skyminds.net était indisponible au petit matin, deux jours de suite. C’est exceptionnellement rare : la configuration du serveur dédié OVH Apollo est stable et n’est jamais modifiée sur un coup de tête.
Après quelques heures à éplucher les logs et le statut des services, le constat était clair : des requêtes épuisaient les workers NginX à une vitesse anormale, sans pic de trafic visible côté Cloudflare ni signe d’attaque volumétrique classique. Le coupable n’était donc pas une simple charge excessive, mais un mécanisme bien plus sournois.
La cause : la faille HTTP/2 Bomb
Une attaque par déni de service baptisée HTTP/2 Bomb touche plusieurs serveurs web majeurs : NginX, Apache HTTPD, Microsoft IIS, Envoy et Cloudflare Pingora. Elle combine deux mécanismes connus du protocole HTTP/2 : la compression d’en-têtes HPACK et le contrôle de flux. L’attaquant alimente la table de compression avec une entrée volumineuse, puis envoie de nombreuses références d’un seul octet vers cette entrée, forçant le serveur à reconstruire des en-têtes massifs à chaque requête tout en maintenant la connexion ouverte grâce à des mises à jour de fenêtre périodiques. Résultat : un attaquant disposant d’une simple connexion domestique peut rendre un serveur indisponible en quelques secondes, sans authentification ni botnet.
Plusieurs éditeurs de sécurité utilisent l’identifiant CVE-2026-49975 comme nom générique de cette chaîne d’attaque. Dans les faits, NginX a livré son correctif sans CVE dédiée, tandis que ce numéro concerne plus précisément Apache HTTP Server (module mod_http2) ; Envoy a reçu son propre identifiant. Le ratio d’amplification mesuré reste plus modeste sur NginX que sur les autres serveurs concernés, mais suffisant pour dégrader durablement le service sous une attaque soutenue.
Lire la suite
