# Debian et Ubuntu : mon paquet PHP est-il corrigé ?

> Paquet PHP corrigé contre PHP2Shell sous Debian ou Ubuntu ? Niveaux de paquets corrigés par version, commandes de vérification et pièges pour les admins.

Source : https://phpsos.de/fr/blog/debian-ubuntu-paket-gepatcht/  
É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 :** que votre paquet PHP soit corrigé contre PHP2Shell sous Debian ou Ubuntu, vous le reconnaissez au niveau exact du paquet, non à la version de PHP. Ubuntu a publié le 21 octobre 2026 des paquets corrigés pour toutes les versions prises en charge, les plus anciennes via Ubuntu Pro. Debian a corrigé php8.2 dans bookworm et php8.4 dans trixie. Comparez le niveau installé avec `dpkg --compare-versions` et redémarrez ensuite tous les services PHP.

## La question derrière la question

« Mon paquet PHP est-il corrigé ? » semble une question à réponse oui ou non. En pratique, la réponse dépend de trois choses : de quelle source provient le paquet, quel niveau est installé et ce niveau est-il aussi celui qui tourne ? Cet article répond aux deux premiers points pour les paquets officiels de Debian et d'Ubuntu. La manière de vérifier en général la version et les processus en cours figure sous [Bien vérifier la version de PHP et le niveau de correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/).

Nous avons consulté les indications des avis de sécurité officiels d'Ubuntu et du Debian Security Tracker le 25 octobre 2026. Les deux CVE, CVE-2026-109618 et CVE-2026-109619, y figurent avec les mêmes niveaux corrigés.

## Niveaux de paquets corrigés chez Ubuntu

Ubuntu a publié les corrections avec deux avis. USN-8948-1 couvre les versions actuelles, USN-8948-2 les plus anciennes, qui ne reçoivent plus de mises à jour de sécurité que via Ubuntu Pro. Pour 16.04 et 14.04, Ubuntu cite en outre l'offre Legacy Support.

| Version d'Ubuntu | Paquet source | Niveau corrigé |
|---|---|---|
| 26.10 | php8.5 | 8.5.9-0ubuntu2.1 |
| 26.04 LTS | php8.5 | 8.5.4-0ubuntu1.5 |
| 24.04 LTS | php8.3 | 8.3.6-0ubuntu0.24.04.13 |
| 22.04 LTS | php8.1 | 8.1.2-1ubuntu2.28 |
| 20.04 LTS (Ubuntu Pro) | php7.4 | 7.4.3-4ubuntu2.29+esm5 |
| 18.04 LTS (Ubuntu Pro) | php7.2 | 7.2.24-0ubuntu0.18.04.17+esm14 |

Il est frappant que tous les niveaux conservent la version d'origine de PHP. Ubuntu 24.04 reste en 8.3.6, bien que la correction ait été reprise de 8.3.36. Pourquoi il en est ainsi et comment s'en accommoder, l'article [Pourquoi php -v affiche le même numéro](https://phpsos.de/fr/blog/php-v-zeigt-alte-nummer/) l'explique. Sont concernés, entre autres, les paquets binaires pour FPM, CLI, CGI et le module Apache, par exemple `php8.3-fpm` et `libapache2-mod-php8.3`.

## Niveaux de paquets corrigés chez Debian

Debian emprunte ici une autre voie et livre les nouvelles versions amont. Selon le Security Tracker, l'état est le suivant :

| Version de Debian | Paquet source | Niveau précédent | Niveau corrigé | Avis |
|---|---|---|---|---|
| 12 bookworm | php8.2 | 8.2.32-1~deb12u1 | 8.2.35-1~deb12u1 | DLA-4848-1 |
| 13 trixie | php8.4 | 8.4.24-1~deb13u1 | 8.4.27-1~deb13u1 | DSA-6574-1 |
| forky, sid | php8.4 | | 8.4.27-1 | |

L'avis pour bookworm est paru comme DLA, donc via Debian LTS. Pour php8.2 dans unstable, le tracker n'indique pas encore de niveau corrigé lors de la consultation. Qui exploite des systèmes de test sur unstable devrait garder cela à l'œil.

Les anciennes versions de Debian n'apparaissent pas dans les deux entrées CVE lors de la consultation. Si un serveur tourne encore sur une telle version, par exemple Debian 11 avec PHP 7.4, vous ne pouvez pas compter sur une mise à jour de sécurité de l'archive officielle. Il reste alors trois voies : passer le système d'exploitation à une version prise en charge, recourir à une offre commerciale de support à long terme dont vous vous faites confirmer par écrit la couverture pour PHP2Shell, ou sécuriser le serveur par des mesures transitoires jusqu'à la migration et restreindre son accessibilité. À long terme, seule la première voie est viable.

## Comment comparer exactement le niveau installé

Un regard sur le numéro de version ne suffit pas, car les versions Debian sont triées selon leurs propres règles. `dpkg --compare-versions` compare correctement. Les commandes suivantes sont en lecture seule ; adaptez les noms de paquets et le niveau cible à votre version.

```bash
# Niveau installé et origine du paquet
apt policy php8.3-fpm

# Tous les paquets PHP installés avec leur version
dpkg-query -W -f='${Package}\t${Version}\n' 'php*' 'libapache2-mod-php*' 2>/dev/null

# Comparaison exacte avec le niveau corrigé (exemple Ubuntu 24.04)
v=$(dpkg-query -W -f='${Version}' php8.3-fpm)
dpkg --compare-versions "$v" ge 8.3.6-0ubuntu0.24.04.13 && echo "korrigiert: $v" || echo "PRÜFEN: $v"
```

Dans la sortie de `apt policy`, prêtez attention à la ligne de la source du paquet. Si ce n'est pas l'archive de sécurité de votre distribution qui y figure, mais par exemple `packages.sury.org` ou un PPA, les tableaux ci-dessus ne s'appliquent pas. C'est alors le niveau de cette source tierce qui compte, que nous traitons dans l'article [Le dépôt sury.org](https://phpsos.de/fr/blog/sury-repository-php/).

Un regard sur le changelog fourni vaut en outre la peine. La manière d'y trouver les numéros CVE et de les consigner comme preuve est décrite dans l'article [Prouver les numéros CVE dans le changelog du paquet](https://phpsos.de/fr/blog/cve-im-changelog-nachweisen/).

## Pièges typiques lors de la vérification

**Un seul paquet vérifié :** PHP se compose de nombreux paquets binaires. Si `php8.3-cli` est à jour mais pas `php8.3-fpm`, le site reste ouvert. Vérifiez tous les paquets d'une branche, en particulier FPM, CGI et le module Apache.

**Paquet retenu :** les paquets figés par `apt-mark hold` restent en place lors de la mise à jour. `apt-mark showhold` les affiche.

**Ubuntu Pro non activé :** sur 20.04 et plus ancien, les corrections n'arrivent que si Ubuntu Pro est configuré. Sans Pro, le système reste vulnérable malgré l'exécution de la mise à jour.

**Miroir obsolète :** si le serveur obtient les paquets via un miroir ou un proxy interne, il ne voit les nouvelles mises à jour de sécurité qu'une fois celui-ci mis à jour. Dans le doute, vérifiez que `apt update` atteint bien la source de sécurité.

**Redémarrage oublié :** les nouveaux paquets n'agissent qu'après le redémarrage de tous les services qui ont chargé PHP. `needrestart`, s'il est installé, montre les services avec un code obsolète.

> **Important:**
> Un niveau de paquet corrigé prouve seulement que la faille est fermée à partir de maintenant. Il ne dit pas si le serveur a été attaqué auparavant. Sauvegardez les journaux à partir du 20 octobre.

## Comment PHP SOS aide-t-il concrètement ?

- Nous déterminons pour chaque serveur l'origine de tous les paquets PHP et comparons le niveau avec les avis officiels.
- Nous installons les mises à jour, y compris via Ubuntu Pro, et redémarrons tous les services concernés.
- Avec le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/), vous recevez pour chaque serveur une preuve avec niveau du paquet, correspondance dans le changelog et heure du redémarrage.
- Sur les systèmes avec sources tierces ou anciennes versions, nous clarifions quelle voie mène à un niveau corrigé justifiable.


## Questions fréquentes

**Quelle version d'Ubuntu contient la correction de PHP2Shell ?**  
Selon USN-8948-1, Ubuntu 22.04, 24.04, 26.04 et 26.10 reçoivent des mises à jour régulières. Pour 14.04, 16.04, 18.04 et 20.04, Ubuntu livre les corrections via Ubuntu Pro selon USN-8948-2.

**Pourquoi Ubuntu 24.04 affiche-t-il toujours PHP 8.3.6 ?**  
Ubuntu reprend les corrections de sécurité sous forme de rétroportage dans la version existante. Le numéro amont reste 8.3.6, seul le niveau du paquet change. Selon USN-8948-1, le niveau corrigé est 8.3.6-0ubuntu0.24.04.13.

**Debian 12 bookworm est-elle encore prise en charge ?**  
Oui. Selon le Debian Security Tracker, il existe pour php8.2 dans bookworm le niveau corrigé 8.2.35-1~deb12u1, annoncé comme DLA-4848-1 dans le cadre de Debian LTS.

**Cela vaut-il aussi pour PHP du dépôt sury ?**  
Non. Les paquets de sources tierces comme sury.org ont leurs propres niveaux de version et leurs propres changelogs. Les indications de Debian et d'Ubuntu ne valent que pour leurs paquets officiels.

**Un apt upgrade suffit-il ?**  
Il installe les nouveaux paquets, mais les processus PHP-FPM ou Apache en cours conservent l'ancien code en mémoire. Seul un redémarrage de tous les services qui chargent PHP rend le correctif effectif.

## Sources

- [Ubuntu Security Notice USN-8948-1](https://ubuntu.com/security/notices/USN-8948-1)
- [Ubuntu Security Notice USN-8948-2](https://ubuntu.com/security/notices/USN-8948-2)
- [Debian Security Tracker: CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618)
- [Debian Security Tracker: CVE-2026-109619](https://security-tracker.debian.org/tracker/CVE-2026-109619)
