Maintenance Ubuntu : 83 paquets mis à jour et vérifiés

#Un périmètre précis pour les mises à jour Ubuntu

Les paquets provenaient des dépôts habituels Ubuntu, dont les métadonnées signées ont été vérifiées. Avant l’installation, nous avons comparé les versions présentes, les versions proposées et les changements attendus. Le résultat final correspond aux 83 mises à jour prévues, sans ajout ni suppression de paquet.

Systemd passe en version 259.9-0ubuntu0.1. Ubuntu reste en version 26.04 LTS. Cette intervention conserve les versions du noyau, de Node.js, de Docker et de PostgreSQL, ainsi que les versions applicatives déjà déployées. Elle ne demande aucune mise à jour du paquet npm PRNext dans vos projets.

#Le suivi du noyau reste une opération distincte

Après redémarrage, les deux serveurs exécutent toujours 7.0.0-43-generic, issu des paquets Ubuntu 7.0.0-43.43 installés le 3 novembre. Ces paquets officiels ont été sélectionnés dans le dépôt de qualification -proposed, après une décision spécifique et des contrôles dédiés, sans activation globale de ce dépôt.

Lors de notre vérification du 5 novembre, le suivi officiel Ubuntu décrit encore cette version comme en cours de qualification pour Ubuntu 26.04 LTS. Les 83 mises à jour de cette nouvelle maintenance ne constituent donc pas un nouveau correctif de CVE-2026-98432. Notre précédent article explique le choix du noyau et la différence entre paquet disponible, canal de diffusion et noyau réellement démarré.

suivi officiel Ubuntu

Notre précédent article

#Pourquoi redémarrer avec le même noyau ?

Remplacer une bibliothèque sur le disque ne renouvelle pas automatiquement la copie déjà chargée par un processus. Après l’installation, notre contrôle signalait encore des services utilisant d’anciennes bibliothèques. Nous avons donc redémarré les VPS successivement, avec une vérification du premier avant l’intervention sur le second.

Après chaque redémarrage, une nouvelle connexion SSH a confirmé le retour de l’accès d’administration. Les contrôles finaux ne signalaient plus de service utilisant les anciennes bibliothèques. La configuration SSH et les accès existants ont été conservés. Ce résultat explique le redémarrage même si aucun nouveau noyau n’avait été installé pendant cette maintenance.

#Vérifier les services après le démarrage

Nous avons contrôlé la résolution DNS, les réponses HTTPS publiques et la disponibilité de PostgreSQL, avec une requête simple confirmant que la base répondait. Les cinq points d’accès natifs des applications ont également renvoyé une réponse HTTPS 200, avec la validation TLS habituelle.

Trois conteneurs étaient initialement en veille après le redémarrage. Les requêtes de contrôle HEAD sur leurs adresses natives les ont réveillés par le mécanisme normal de la plateforme. Les cinq conteneurs ont ensuite été observés en fonctionnement avec les mêmes identifiants et les mêmes images. Ces contrôles attestent la reprise des points d’accès testés ; ils ne remplacent pas la validation de tous les parcours métier d’une application.

Le filtrage réseau temporaire et la désactivation de MPTCP sont restés en place. Nous avons vérifié les règles après démarrage et les réglages MPTCP dans tous les espaces réseau observés, y compris après le réveil des conteneurs. Ces protections gardent leurs limites et ne remplacent pas le correctif du noyau.

#Les paquets différés restent sous contrôle

Sept paquets sur chaque serveur restaient soumis au déploiement progressif d’Ubuntu. Nous avons conservé ce mécanisme sans forcer leur installation. La documentation Ubuntu explique qu’il distribue certaines mises à jour par étapes pour limiter les effets d’une éventuelle régression.

La même documentation précise que les mises à jour de sécurité ne sont jamais soumises à ce déploiement progressif. Un message indiquant des paquets différés demande donc une lecture de leur état réel, plutôt qu’une commande générale qui contournerait cette protection.

documentation Ubuntu

#Ce qu’il faut retenir pour votre VPS

Les 83 paquets correspondent à l’état de nos serveurs au moment de l’intervention. Votre distribution, vos dépôts et vos logiciels installés produiront un autre résultat. Comparez le plan de mise à jour avec votre installation, préparez une solution de récupération et vérifiez les services dont votre application dépend après leur renouvellement.

Le suivi reste daté : des versions disponibles aujourd’hui peuvent évoluer demain. Pour le noyau, consultez la fiche Ubuntu correspondant à la vulnérabilité et à votre famille de paquets. Pour l’application, testez aussi les fonctions qui comptent pour vos utilisateurs. Une réponse HTTP réussie apporte une preuve utile, dont le périmètre doit rester clair.