Mise à jour Apache sur Ubuntu - quand un correctif de sécurité empêche le serveur de redémarrer

Une mise à jour Apache sur Ubuntu 20.04 LTS destinée à corriger plusieurs vulnérabilités a introduit une régression capable d’empêcher le serveur web de démarrer. La condition identifiée par Canonical est précise: le problème pouvait apparaître lorsque le proxy HTTP/2 était activé.

Canonical a publié le 10 septembre 2026 l’avis USN-8571-2 pour corriger cette régression. L’éditeur explique que le précédent correctif était incomplet à cause d’un symbole de bibliothèque manquant. La version corrigée indiquée pour Ubuntu 20.04 LTS est 2.4.41-4ubuntu3.23+esm7, distribuée dans le cadre d’Ubuntu Pro.

Le cas ne justifie pas de retarder toutes les mises à jour. Il illustre plutôt une réalité de l’exploitation: installer un correctif de sécurité ne suffit pas. Il faut savoir quels serveurs sont concernés, vérifier leurs fonctions réelles, organiser le redémarrage, observer le service et disposer d’une solution de repli.

C’est précisément l’un des rôles d’un prestataire d’infogérance de serveurs Linux: transformer une mise à jour disponible en changement maîtrisé, avec un périmètre, des contrôles et une responsabilité opérationnelle.

Le correctif de sécurité protégeait contre plusieurs vulnérabilités Apache

L’avis initial USN-8571-1, publié le 20 juillet 2026, regroupait plusieurs corrections de sécurité pour Apache HTTP Server sur différentes versions d’Ubuntu encore couvertes par les services de maintenance étendue.

Les problèmes corrigés concernaient notamment:

• des dénis de service dans plusieurs modules;
• une séparation incorrecte des réponses HTTP avec des backends non fiables ou compromis;
• des divulgations d’informations;
• des traitements incorrects dans mod_proxy_ajp, mod_ssl, WebDAV ou mod_http2;
• une vulnérabilité liée aux expressions régulières pouvant, dans certaines configurations, conduire à une exécution de code ou à un déni de service.

La mise à jour avait donc une vraie finalité de sécurité. La régression ne transforme pas rétroactivement le correctif en mauvaise décision. Elle révèle qu’un paquet peut résoudre une exposition tout en créant un nouveau risque de disponibilité sur un sous-ensemble d’installations.

Le choix opérationnel ne se résume alors ni à « patcher immédiatement partout » ni à « attendre que les autres essuient les plâtres ». Il consiste à réduire simultanément le risque de compromission et le risque d’interruption.

La régression concernait le proxy HTTP/2

Selon Canonical, Apache pouvait échouer au démarrage lorsque le proxying HTTP/2 était activé. Ce point mérite d’être lu précisément.

Servir un site en HTTP/2 aux navigateurs ne prouve pas, à lui seul, que le serveur utilise HTTP/2 pour communiquer avec ses backends. La fonction concernée peut notamment apparaître avec le module proxy_http2 et des destinations déclarées en h2:// ou h2c://.

Un premier contrôle peut être réalisé avec:

apache2ctl -M | grep -E 'http2|proxy'

Il faut ensuite examiner la configuration effectivement chargée, y compris les fichiers inclus, les virtual hosts et les fragments générés par l’automatisation. Un inventaire CMDB trop général, indiquant seulement « Apache », ne permet pas d’identifier ce type de condition.

Ce détail est important pour prioriser. Une flotte peut comporter des serveurs Ubuntu 20.04 qui n’utilisent pas le proxy HTTP/2, quelques reverse proxies qui l’activent et des hôtes de test déjà migrés vers une version plus récente. Tous ne présentent pas le même risque ni la même urgence de redémarrage.

Une mise à jour réussie ne se limite pas à la sortie de la commande apt

Sur un serveur de production, la fin sans erreur de apt ne constitue pas une validation de service.

Le paquet peut être installé alors que:

• le processus actif utilise encore l’ancien binaire ou d’anciennes bibliothèques;
• le service ne pourra plus démarrer au prochain reboot;
• un module dynamique ne peut plus être chargé;
• Apache répond, mais certains virtual hosts ou backends sont indisponibles;
• PHP-FPM, une application ou une base de données sature après la reprise du trafic;
• le load balancer continue d’envoyer des requêtes vers un nœud dégradé.

La régression USN-8571-2 est particulièrement parlante: tant qu’Apache reste en mémoire, un défaut de démarrage peut rester invisible. Le risque se matérialise lors du redémarrage du service, d’une maintenance ultérieure ou d’un reboot imprévu.

Repousser indéfiniment le redémarrage ne corrige donc rien. Cela déplace l’incident vers un moment moins préparé.

Avant de patcher, il faut établir le périmètre réel

Une procédure de mise à jour commence par des questions simples:

1. quels hôtes utilisent Ubuntu 20.04 LTS et Apache;
2. quelles versions des paquets sont installées et proposées;
3. quels modules sont chargés;
4. où le proxy HTTP/2 est réellement utilisé;
5. quels services et noms de domaine dépendent de chaque nœud;
6. quelle capacité reste disponible si un serveur est retiré du trafic;
7. comment restaurer le service si le nouveau paquet ne démarre pas.

Les versions installées et candidates peuvent être contrôlées avec:

apt-cache policy apache2 apache2-bin apache2-data

La configuration doit également être validée avant l’intervention:

apache2ctl configtest

Ce contrôle reste nécessaire, mais il n’est pas suffisant. Un Syntax OK ne teste ni le chargement du futur binaire, ni le fonctionnement des bibliothèques mises à jour, ni le parcours complet d’une requête jusqu’à l’application.

Lorsque la cartographie n’existe pas, la fenêtre de maintenance devient une phase de découverte. C’est l’une des raisons pour lesquelles nous recommandons de cartographier les dépendances avant une reprise d’infogérance.

Déployer par vagues limite le rayon d’impact

Sur une infrastructure redondée, la mise à jour peut être appliquée à un premier nœud retiré du trafic. Après installation, Apache doit être redémarré, puis le serveur soumis à des tests techniques et applicatifs avant sa réintégration.

Un déroulé raisonnable comprend:

1. confirmer l’état sain de la plateforme avant changement;
2. retirer le nœud pilote du load balancer;
3. sauvegarder la configuration et consigner les versions en place;
4. appliquer les paquets ciblés;
5. lancer le configtest puis redémarrer réellement Apache;
6. vérifier le processus, les ports, les journaux et les virtual hosts;
7. tester les parcours applicatifs depuis l’extérieur;
8. réinjecter progressivement le trafic;
9. observer les métriques avant de poursuivre sur le nœud suivant.

Sur un serveur unique, la même discipline reste utile, mais elle ne supprime pas l’interruption potentielle. Il faut alors choisir une fenêtre adaptée, prévenir les parties concernées et préparer une capacité temporaire ou un scénario de restauration suffisamment rapide.

Cette différence montre pourquoi la haute disponibilité n’est pas uniquement une réponse aux pannes matérielles. Elle permet aussi d’effectuer des maintenances de sécurité sans engager toute la production à chaque changement.

La supervision doit valider le service, pas seulement le processus

Après le redémarrage, systemctl is-active apache2 confirme que systemd considère le service actif. Ce signal ne dit pas si l’ensemble de la plateforme fonctionne correctement.

La validation doit croiser au minimum:

• l’état du service et les journaux Apache;
• les codes HTTP, notamment les réponses 5xx;
• la latence des pages et des API importantes;
• les erreurs de connexion aux backends;
• l’état de PHP-FPM ou des runtimes applicatifs;
• la pression CPU, mémoire, disque et réseau;
• les files d’attente et connexions aux bases de données;
• un test synthétique réalisé depuis l’extérieur de l’infrastructure.

Une simple page d’accueil en cache peut répondre en 200 alors que l’authentification, le paiement ou l’administration sont déjà en panne. La supervision d’une infrastructure doit donc suivre les services rendus et leurs dépendances, pas uniquement la présence des processus.

Le retour arrière doit être préparé avant le changement

Un rollback improvisé après un échec prend plus de temps et augmente le risque d’erreur. Avant la mise à jour, l’équipe doit savoir quelle action rétablit le service:

• maintenir le trafic sur les nœuds non modifiés;
• remettre en service une instance validée;
• restaurer un snapshot cohérent lorsque cette méthode est adaptée;
• réinstaller une version de paquet conservée et validée;
• restaurer les configurations modifiées;
• basculer vers un site ou un environnement de reprise.

Le choix dépend de l’architecture et des données manipulées. Restaurer un snapshot de serveur web stateless n’a pas les mêmes conséquences que revenir en arrière sur une machine qui héberge aussi une base de données active.

Il faut également définir un point d’arrêt. Si les tests échouent, si la latence dérive ou si les erreurs augmentent, le déploiement doit être interrompu avant que la vague suivante ne reproduise le problème.

Faut-il désactiver les mises à jour automatiques ?

Cette régression peut inciter à désactiver tous les correctifs automatiques. Ce serait une conclusion dangereuse.

Sans politique de mise à jour, les vulnérabilités s’accumulent et les interventions deviennent plus lourdes. À l’inverse, appliquer sans contrôle chaque paquet sur toute la production transforme une flotte homogène en rayon d’impact unique.

La bonne réponse dépend de la criticité des systèmes:

• automatiser l’inventaire et la détection des mises à jour;
• qualifier la gravité et l’exposition réelle;
• séparer les environnements ou les vagues de déploiement;
• imposer des contrôles avant et après redémarrage;
• conserver une capacité de retrait et de rollback;
• tracer les résultats et les exceptions;
• vérifier que les serveurs en maintenance étendue reçoivent effectivement les paquets attendus.

Nous détaillons cette logique dans notre article sur la manière de patcher les failles Linux sans interrompre les services.

Une alerte de paquet devient un sujet d’infogérance

USN-8571-2 porte sur un périmètre limité: Ubuntu 20.04 LTS, les paquets Apache concernés et l’usage du proxy HTTP/2. Pourtant, la méthode nécessaire pour le traiter s’applique à toute infrastructure Linux.

Il faut relier une alerte éditeur à l’inventaire réel, comprendre la fonction du composant, décider d’une priorité, déployer avec une marge de sécurité et vérifier le résultat du point de vue de l’utilisateur.

La valeur n’est pas dans la seule commande de mise à jour. Elle se trouve dans la capacité à corriger rapidement sans découvrir les dépendances pendant l’incident.

Dans le cadre de notre infogérance de serveurs Linux, nous prenons en charge la veille, la qualification, les mises à jour, la supervision et les procédures de reprise. L’objectif est de maintenir les systèmes en condition de sécurité tout en conservant la maîtrise de leur disponibilité.

• Découvrir notre offre d’infogérance Linux
• Demander un pré-audit d’infogérance
• Prendre rendez-vous

Sources

• Canonical - USN-8571-2 - régression Apache HTTP Server
• Canonical - USN-8571-1 - vulnérabilités Apache HTTP Server
• Launchpad - suivi de la régression du paquet Apache

FAQ: mise à jour Apache sur Ubuntu et continuité de service

Quelle mise à jour Apache a introduit cette régression sur Ubuntu ?

Canonical indique que le correctif USN-8571-1 était incomplet en raison d’un symbole de bibliothèque manquant. Sur Ubuntu 20.04 LTS, Apache pouvait alors ne plus démarrer lorsque le proxy HTTP/2 était activé.

Quelle version corrige la régression Apache sur Ubuntu 20.04 LTS ?

L’avis USN-8571-2 indique la version 2.4.41-4ubuntu3.23+esm7 pour les paquets Apache concernés sur Ubuntu 20.04 LTS avec Ubuntu Pro. Une version ultérieure fournie par les dépôts Ubuntu intègre également le correctif.

Faut-il arrêter les mises à jour automatiques à cause de cette régression ?

Non. Désactiver durablement les correctifs augmente l’exposition aux vulnérabilités. Il faut plutôt organiser les mises à jour par vagues, tester les configurations concernées, superviser le redémarrage et préparer un retour arrière.

Comment savoir si un serveur utilise le proxy HTTP/2 d’Apache ?

Il faut vérifier les modules Apache chargés, notamment proxy_http2, puis rechercher les destinations h2:// ou h2c:// dans la configuration. La présence du protocole HTTP/2 côté client ne signifie pas nécessairement que le proxy HTTP/2 est utilisé vers les backends.

Un configtest Apache suffit-il avant une mise à jour ?

Non. Le configtest détecte surtout les erreurs de syntaxe et certaines incohérences de configuration. Il ne garantit pas que le nouveau binaire chargera toutes ses bibliothèques ni que les backends, PHP, les proxys et les applications resteront fonctionnels après redémarrage.