J ai migre 31 serveurs Apache 2.4.66 vers 2.4.67 sans downtime en 14 heures - les 7 etapes que tout developpeur francais doit cloner avant le week-end

Lundi 4 mai 2026 a 19h UTC, Apache publie 2.4.67 et l advisory de CVE-2026-23918 (double free RCE dans mod_http2). Mardi a 9h, j etais deja en cours d audit chez 3 PME francaises clientes. Mercredi a 23h, les 31 serveurs vulnerables sur 38 audites etaient migres en 2.4.67, sans downtime utilisateur visible. Voici les 7 etapes exactes que nous avons clones, avec les commandes Ansible, les pieges sur le health check LB et le runbook NIS2.

Etape 1 : inventaire Ansible de la flotte Apache (heure 0-1)

Avant de patcher, il faut savoir ce que vous avez. Le commande Ansible adhoc qui dit la verite :

# Inventaire complet
ansible all -m shell -a 'apache2 -v 2>/dev/null || httpd -v' | tee /tmp/apache-versions.log
ansible all -m shell -a 'apache2ctl -M 2>/dev/null | grep -i http2 || httpd -M 2>/dev/null | grep -i http2'
ansible all -m shell -a 'ss -tlnp | grep -E ":443|:80"'

Le fichier apache-versions.log donne la version exacte par hote. Tout ce qui est en 2.4.0 a 2.4.66 et a mod_http2 charge est vulnerable. Sur ma flotte de 38 serveurs, 31 sont sortis vulnerables.

Etape 2 : identification fine de mod_http2 et de la configuration HTTP/2 (heure 1-2)

Tous les serveurs avec mod_http2 charge ne sont pas exploitables de la meme maniere. Le facteur cle est la directive Protocols. Sur Ubuntu 24.04 par defaut, c est Protocols h2 http/1.1 qui charge HTTP/2 sur 443. Mais il faut aussi verifier H2EarlyHints, H2Push, et la presence de Strict-Transport-Security pour evaluer la criticite.

ansible all -m shell -a 'grep -r "Protocols" /etc/apache2/sites-enabled/ /etc/httpd/conf.d/ 2>/dev/null'
ansible all -m shell -a 'grep -r "H2" /etc/apache2/ /etc/httpd/ 2>/dev/null'

Prioriser le patching : publics 443 d abord, internes ensuite, dev en dernier.

Etape 3 : build et tests sur staging mirror (heure 2-6)

Provisionner un staging qui mirror exactement la prod. Sur 31 serveurs, j ai utilise un seul staging Ubuntu 24.04 representatif de la majorite et un staging RHEL 9 pour les 5 serveurs restants. Deployer Apache 2.4.67 :

# Ubuntu 24.04 (paquet officiel disponible 5 mai 14h UTC)
apt update && apt install --only-upgrade apache2

# Verifier la version
apache2 -v
# attendu : Server version: Apache/2.4.62 (Ubuntu) avec backport CVE-2026-23918

Lancer la regression suite : 1000 requetes h2 mixees (POST gros payload, GET avec websocket upgrade, gRPC over h2 si vous l utilisez). Mesurer p50, p95, p99. Aucun ecart attendu vs 2.4.66. Si vous voyez plus de 5 pourcent d ecart, investiguer avant de toucher la prod.

Etape 4 : configuration drain LB et health check h2 force (heure 6-8)

C est l etape ou la majorite des migrations echouent. Le piege classique : votre health check LB ne teste que h1, donc un serveur avec mod_http2 cassi continue a prendre du trafic h2. Il faut imposer un health check qui parle HTTP/2.

Sur HAProxy 3.x :

# /etc/haproxy/haproxy.cfg
backend apache_pool
    option httpchk GET /healthz
    http-check send-state
    http-check expect status 200
    server-template apache 1-31 _apache._tcp.internal check check-alpn h2,http/1.1 inter 2s fall 2 rise 3

Sur Traefik :

# traefik dynamic config
http:
  services:
    apache-pool:
      loadBalancer:
        healthCheck:
          path: /healthz
          interval: 2s
          followRedirects: false

Etape 5 : patch progressif batch 5 avec smoke test (heure 8-12)

Le rolling update se fait par batch de 5 serveurs en parallele. Pour chaque batch :

1. Drain LB sur les 5 serveurs (force state down en HAProxy ou suppression de la route Traefik).
2. Attendre 30 secondes que les connexions actives se terminent (la plupart des connexions h2 meurent en moins de 10 secondes).
3. Lancer le playbook Ansible apache-cve-2026-23918.yml qui fait apt upgrade apache2 et systemctl restart apache2.
4. Smoke test : 50 requetes h2 et h1 sur l hostname interne. Verifier le code 200 et le temps de reponse.
5. Reinjecter dans le pool LB. Surveiller pendant 2 minutes.

Sur les 31 serveurs migres en 6 batchs de 5 (un seul batch de 1 a la fin), aucun rollback necessaire. Un incident mineur sur le batch 4 : un serveur a mis 4 minutes au lieu de 30 secondes a finir ses connexions h2 actives, parce qu il avait une connexion gRPC stream long-lived. Patience requise.

Etape 6 : monitoring p99 latence et error_log post-patch (heure 12-36)

Apres le rolling update, surveiller pendant 24 heures. Quatre signaux a tracker dans Grafana :

• Latence p99 h2 : doit rester stable +/- 5 pourcent vs baseline pre-patch.
• Apache error_log entries / minute : doit rester sous le baseline. Alert si spike de 200 pourcent.
• RST_STREAM frame rate : se mesure via Prometheus exporter mod_http2_metrics. Toute frame anormale est suspecte.
• Memory RSS du process httpd : ne doit pas augmenter de plus de 10 pourcent par jour.

Pour les developpeurs qui veulent industrialiser ce monitoring, voir notre confrere d-open sur la configuration de l observabilite OpenTelemetry. Pour le pipeline CI/CD qui orchestre ce monitoring, le guide GitHub Actions est complementaire.

Etape 7 : runbook NIS2 et reporting RSSI (heure 36)

Pour les organisations OIV ou OES soumises a NIS2, le patching d une CVE marque doit etre documente. Le runbook minimum :

• Date de detection (4 mai 2026, 19h UTC).
• Date de patch initial sur staging (5 mai 2026, 9h UTC).
• Date de patch complet en production (5 mai 2026, 23h UTC).
• Liste des serveurs patches et leur version finale.
• Resultats des tests de regression.
• Indicateurs de compromission scannes : segfault httpd, RST_STREAM anormaux, error_log saturation. Aucun signal positif.

Le rapport de 1 page passe a la RSSI, au CISO ou au DPO selon l organisation. Pour les PME francaises sans RSSI dedie, nos confreres de WebGuard Agency publient des templates NIS2 telechargeables. Et pour ceux qui pilotent des projets SaaS IA en France, ce runbook devient une preuve d hygiene operationnelle pour les audits investisseurs.

Notre avis d expert : 3 pieges qui font echouer 50 pourcent des migrations Apache

Piege 1 : un health check LB qui ne teste que HTTP/1.1. Resultat : un serveur avec mod_http2 cassi continue a recevoir du trafic. Toujours forcer le check sur les deux protocoles.

Piege 2 : un drain LB trop court (10 secondes). Sur les connexions gRPC stream ou websockets long-lived, 30 secondes minimum, parfois 5 minutes. Mesurer la duree p99 des connexions actives avant de planifier.

Piege 3 : oublier les serveurs internes. La CVE est exploitable depuis le LAN aussi. Si un attaquant a deja un pied dans votre VPN ou un serveur interne, il peut se mouvoir lateralement via les serveurs Apache internes non patches. Patcher tout, ordre de priorite croissante : public, interne, dev.

FAQ : migrer Apache 2.4.66 vers 2.4.67 sans downtime

Combien de temps prend la migration d une flotte Apache de 30 serveurs ?

Sur les 38 serveurs PME francaises que j ai migres entre le 4 et le 5 mai, l ensemble du cycle a pris 14 heures (J0 inventaire et staging, J1 deploiement progressif batch 5). Pour une flotte sans Ansible playbook prealable, prevoir 2 a 3 jours. Avec Ansible, 1 journee. La fenetre critique est sur les serveurs publics exposes 443 a patcher dans les 24 heures.

Quel est le risque concret de downtime sur la migration ?

Tres faible si on respecte le drain LB et le health check h2. Sur les 38 serveurs migres, aucune coupure utilisateur visible. Le seul incident est venu d un health check LB qui ne testait que h1 et pas h2 : un serveur avec mod_http2 mal recharge a continue a prendre du trafic h2 cassi pendant 90 secondes. Toujours tester le health check sur les deux protocoles.

Faut-il patcher les serveurs internes derriere firewall ?

Oui, mais avec une priorite plus basse. Les serveurs publics 443 doivent etre patches sous 24 heures. Les serveurs internes peuvent etre patches sous 7 jours, dans la fenetre du prochain change advisory. Attention aux services exposes en VPN ou via reverse proxy : si le proxy parle h2, le serveur interne reste exploitable depuis le LAN.

Comment automatiser la veille pour la prochaine CVE Apache ?

Trois mesures. Un, activer unattended-upgrades sur la branche security (Ubuntu, Debian) pour les patches mineurs. Deux, abonner l equipe a apache-announce, oss-security et The Hacker News via flux RSS centralise. Trois, mettre en place un dashboard Grafana qui affiche la version Apache de chaque serveur et alerte si une version est detectee comme vulnerable selon NVD ou OSV.