# Mises à jour de sécurité automatiques sur les serveurs Linux

> Configurer unattended-upgrades et dnf-automatic : mises à jour de sécurité automatiques, redémarrage des services et sources tierces autorisées.

Source : https://phpsos.de/fr/blog/automatische-sicherheitsupdates/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** avec `unattended-upgrades` sous Debian et Ubuntu et `dnf-automatic` sur la famille RHEL, les serveurs Linux appliquent seuls les mises à jour de sécurité. Pour qu'une mise à jour agisse aussi, les services concernés comme PHP-FPM doivent redémarrer ensuite ; vérifiez-le avec needrestart ou les heures de démarrage des processus. Les sources tierces comme sury.org doivent être expressément autorisées, les conteneurs et les changements de version majeure ne sont pas couverts par l'automatisme.

## Du correctif au serveur : l'automatisme fait gagner du temps

Lorsque php.net a publié, le 21 octobre 2026 à 16 heures, heure allemande, les correctifs contre PHP2Shell, une course a commencé pour les administrateurs. Selon des rapports, les distributions ont livré leurs backports en partie le jour même. Les serveurs dotés de mises à jour de sécurité automatiques pouvaient installer les nouveaux paquets lors de l'exécution planifiée suivante, sans que personne n'ait à intervenir.

C'est la bonne nouvelle. La moins bonne : installé ne veut pas dire efficace. Un service PHP-FPM qui tourne depuis des semaines continue de travailler avec l'ancien code en mémoire tant qu'il n'est pas redémarré. Et les paquets de sources tierces, les conteneurs ou les panneaux d'hébergement avec leur propre gestion de PHP restent souvent hors de portée de l'automatisme.

Cet article montre comment configurer les mises à jour de sécurité automatiques et les compléter pour qu'elles protègent réellement en cas d'urgence.

## unattended-upgrades sous Debian et Ubuntu

Sous Ubuntu, le paquet `unattended-upgrades` est installé par défaut et applique les mises à jour de sécurité. Sous Debian, vous l'installez au besoin. Il est piloté par deux fichiers sous `/etc/apt/apt.conf.d/`.

```bash
sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades
```

Le fichier `20auto-upgrades` détermine si et à quelle fréquence les listes de paquets sont actualisées et les mises à jour appliquées. La valeur est le nombre de jours, `"1"` signifie tous les jours :

```text
// /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
```

Dans `50unattended-upgrades` figure l'indication des sources autorisées pour les mises à jour, du redémarrage éventuel ensuite et de qui reçoit un message. Par défaut, seules les sources de sécurité officielles de la distribution sont autorisées. Selon la documentation d'Ubuntu, il ne suffit pas d'intégrer un dépôt supplémentaire : il doit en plus figurer dans cette liste, sinon l'automatisme l'ignore. Cela concerne par exemple le dépôt tiers sury.org, qui a mis à disposition, selon des rapports, des builds PHP pour toutes les branches de 5.6 à 8.5. Les arrière-plans figurent dans l'article [Le dépôt sury.org](https://phpsos.de/fr/blog/sury-repository-php/).

Un essai à blanc qui ne modifie rien montre si tout est correct :

```bash
sudo unattended-upgrade -v --dry-run
# Journaux des vraies exécutions
ls -l /var/log/unattended-upgrades/
```

## dnf-automatic sur RHEL, AlmaLinux et Rocky Linux

Sur la famille RHEL, `dnf-automatic` remplit la même fonction. La configuration se trouve dans `/etc/dnf/automatic.conf`. Selon la documentation, `upgrade_type = security` ne prend en compte que les mises à jour accompagnées d'un avis de sécurité, et `apply_updates` est désactivé par défaut.

```ini
# /etc/dnf/automatic.conf (extrait)
[commands]
upgrade_type = security
download_updates = yes
apply_updates = yes
reboot = never
```

```bash
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
systemctl list-timers 'dnf-automatic*'
```

Outre `dnf-automatic.timer`, qui suit le fichier de configuration, il existe des timers qui se contentent de signaler, de télécharger ou d'installer toujours. Pour commencer, le timer avec fichier de configuration est le plus facile à suivre.

## La partie sous-estimée : redémarrer les services

Le gestionnaire de paquets remplace des fichiers sur le disque. Les processus en cours conservent l'ancien code en mémoire. Pour PHP, cela signifie : tant que PHP-FPM ou Apache avec mod_php n'ont pas été redémarrés, la faille reste ouverte.

| Outil | Système | Ce qu'il fait |
|---|---|---|
| needrestart | Debian, Ubuntu | détecte les services avec des fichiers périmés ; les redémarre automatiquement par défaut sous Ubuntu à partir de 24.04 |
| `dnf needs-restarting -s` | famille RHEL | liste les services qui devraient être redémarrés |
| `Automatic-Reboot` | unattended-upgrades | redémarre le serveur lorsqu'une mise à jour l'exige ; désactivé par défaut |
| `reboot` | dnf-automatic | `never`, `when-changed` ou `when-needed` |

Selon la documentation d'Ubuntu, les services exclus par needrestart continuent de tourner avec d'anciens fichiers jusqu'au redémarrage manuel. Après chaque mise à jour de PHP, vérifiez donc l'heure de démarrage des processus, comme décrit dans [Redémarrer PHP-FPM et tous les workers](https://phpsos.de/fr/php2shell/php-fpm-neustart/).

> **Important:**
> Avec les backports, le numéro de version de PHP affiché reste souvent le même. Vous prouvez le correctif via le journal des modifications du paquet avec les numéros CVE, par exemple avec `apt-get changelog` ou `rpm -q --changelog`. La démarche détaillée est présentée dans [Debian et Ubuntu : mon paquet PHP est-il corrigé ?](https://phpsos.de/fr/blog/debian-ubuntu-paket-gepatcht/).

## Ce que l'automatisme ne couvre pas

Les mises à jour automatiques sont un élément, pas une gestion complète des correctifs. Certains domaines exigent leurs propres processus :

1. **Conteneurs :** PHP dans les images Docker n'est pas mis à jour par les mises à jour de l'hôte. Reconstruire les images, recréer les conteneurs.
2. **Panneaux d'hébergement :** Plesk, cPanel et panneaux similaires gèrent PHP en partie via leurs propres paquets et mécanismes.
3. **Versions majeures :** le passage par exemple de PHP 8.2, dont le support prend fin le 31 décembre 2026, à une version plus récente ne se fait pas automatiquement.
4. **Applications :** CMS, plugins et dépendances Composer ont leurs propres voies de mise à jour.
5. **Contrôle :** quelqu'un doit lire les journaux et messages d'erreur de l'automatisme. Une exécution qui échoue en silence est pire que pas d'exécution du tout, car elle donne une fausse impression de sécurité.

La manière dont ces éléments se fondent en un processus est décrite dans [Gestion des correctifs comme processus plutôt que pompiers](https://phpsos.de/fr/blog/patch-management-prozess/).

## Conclusion : automatisme oui, confiance aveugle non

Les mises à jour de sécurité automatiques ont leur place sur chaque serveur Linux accessible depuis Internet. PHP2Shell a montré à quel point le temps peut devenir court : selon des rapports des médias, une première tentative d'attaque a été observée dès le 17 octobre, quatre jours avant les correctifs. Qui attend ensuite encore une fenêtre de maintenance manuelle perd un temps précieux.

L'automatisme ne vous décharge toutefois que de l'application. Le redémarrage des services, la preuve du niveau de correctifs, les conteneurs, les panneaux et le passage à temps à des versions prises en charge restent des tâches dont quelqu'un doit être responsable. Fixez cette responsabilité par écrit et vérifiez par sondage que les journaux de l'automatisme sont réellement lus. Seule la combinaison de l'automatisme et du contrôle rend les mises à jour fiables.

## Comment PHP SOS aide-t-il concrètement ?

- **Mettre en place :** nous configurons unattended-upgrades ou dnf-automatic en fonction de vos serveurs, y compris les sources tierces autorisées.
- **Sécuriser les redémarrages :** nous mettons en place needrestart ou des vérifications équivalentes et contrôlons après les mises à jour de PHP les heures de démarrage des processus.
- **Combler les lacunes :** nous intégrons conteneurs, panneaux et changements de version majeure dans un déroulement de maintenance fixe.
- **Contrôler :** dans le cadre du [contrat de maintenance de sécurité](https://phpsos.de/fr/leistungen/security-wartungsvertrag/), nous vérifions les journaux de l'automatisme et signalons les anomalies.


## Questions fréquentes

**Les mises à jour automatiques ne sont-elles pas trop risquées sur des serveurs de production ?**  
Limité aux mises à jour de sécurité de la distribution, le risque est le plus souvent inférieur à celui d'une faille ouverte. Ces mises à jour ne sont pas censées apporter de nouvelles fonctions, mais corriger des erreurs. Pour les systèmes critiques, sauvegardes, supervision et système de test en font partie.

**unattended-upgrades redémarre-t-il PHP-FPM après une mise à jour ?**  
Pas nécessairement de lui-même. Sous Ubuntu, à partir de la version 24.04, l'outil needrestart redémarre par défaut automatiquement les services concernés, mais les services exclus continuent de tourner avec d'anciens fichiers. Après chaque mise à jour de PHP, vérifiez l'heure de démarrage de tous les processus PHP.

**Les paquets de sury.org ou d'autres sources tierces sont-ils mis à jour automatiquement ?**  
Seulement si vous autorisez expressément la source. Selon la documentation d'Ubuntu, il ne suffit pas d'ajouter un dépôt ; il doit en plus figurer dans la liste des origines autorisées d'unattended-upgrades.

**L'automatisme fait-il aussi passer de PHP 8.2 à 8.3 ?**  
Non. Les mises à jour de sécurité automatiques restent dans les versions de paquets installées. Un changement de version majeure de PHP, par exemple avant la fin du support de PHP 8.2 le 31 décembre 2026, reste un projet planifié avec tests.

**Qu'en est-il des conteneurs Docker ?**  
Les mises à jour sur l'hôte ne mettent pas à jour la version de PHP dans les conteneurs. Les images de conteneur doivent être reconstruites ou retirées à nouveau et les conteneurs recréés.

## Sources

- [Ubuntu Server : mises à jour automatiques](https://ubuntu.com/server/docs/how-to/software/automatic-updates/)
- [DNF Automatic](https://dnf.readthedocs.io/en/latest/automatic.html)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)