PHP2Shell sur Ubuntu : pourquoi php -v ne suffit pas pour savoir si vous êtes protégé
Les paquets corrigés pour Ubuntu 22.04, 24.04 et 26.04, quatre commandes pour vérifier votre serveur et les pièges à éviter
Image générée par IA (art. 50 AI Act)
Analyse 2LKATIME
Votre serveur tourne sous Ubuntu, vous tapez php -v et vous lisez 8.3.6. Vous comparez avec l'avis PHP.net, qui parle de 8.3.36, et vous concluez que vous êtes vulnérable. Ou l'inverse. Dans les deux cas, la comparaison est faussée. Cet article explique pourquoi et donne la bonne méthode. Il complète notre article sur les failles PHP.
Un faux sentiment de sécurité coûte cher
Le piège le plus fréquent : une mise à jour faite sans redémarrage du service, ou un contrôle fait avec la mauvaise commande. Les attaques sur PHP2Shell sont observées depuis le 17 octobre : un serveur que l'on croit corrigé sans l'être est le pire cas.
Ubuntu corrige PHP à sa manière. Canonical n'installe pas la version officielle 8.3.36 sur Ubuntu 24.04 : il reporte les correctifs de sécurité dans la version 8.3.6 livrée avec le système. Le numéro affiché ne bouge donc presque pas, et c'est normal.
Ce mode de fonctionnement existe depuis des années sur Ubuntu et Debian. Il rassure les administrateurs, qui n'ont pas de changement de version à tester, et il piège ceux qui se fient aux avis des éditeurs.
1. Pourquoi le numéro de version ne change pas
8.3.6
Version affichée par php -v sur Ubuntu 24.04, même après correctif
8.3.36
Version officielle de PHP qui contient le correctif
21 oct.
Avis Ubuntu USN-8948-1, le jour de la publication des failles
Critique
Priorité Ubuntu pour CVE-2026-109618, score de 9,8 en CVSS 3.1
Le projet PHP a publié le 21 octobre les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12, qui corrigent les failles CVE-2026-109618 et CVE-2026-109619. Le même jour, Ubuntu a publié l'avis USN-8948-1. Il décrit les deux failles comme des exécutions de code à distance, déclenchées par une gestion défaillante de la mémoire et de l'état interne des requêtes. Ubuntu classe la première en priorité critique.
Les paquets Ubuntu ne portent pas les numéros du projet. Un correctif est ajouté à la version d'origine, et c'est la fin du numéro de paquet, après le tiret, qui change. C'est ce suffixe qu'il faut lire.
Cette règle vaut pour tous les paquets Ubuntu, pas seulement PHP. La méthode de vérification ci-dessous sert pour la prochaine alerte sur OpenSSL, nginx ou le noyau.
2. Les paquets corrigés, version d'Ubuntu par version
Voici ce que dit l'avis USN-8948-1. Votre serveur est corrigé si le paquet installé porte ce numéro ou un numéro plus récent.
| Ubuntu | Paquet | Version corrigée | Équivalent officiel |
|---|---|---|---|
| 22.04 LTS (jammy) | php8.1 | 8.1.2-1ubuntu2.28 | Aucune : PHP 8.1 n'est plus corrigé par le projet |
| 24.04 LTS (noble) | php8.3 | 8.3.6-0ubuntu0.24.04.13 | 8.3.36 |
| 26.04 LTS (resolute) | php8.5 | 8.5.4-0ubuntu1.5 | 8.5.12 |
| 26.10 (stonking) | php8.5 | 8.5.9-0ubuntu2.1 | 8.5.12 |
La première ligne mérite attention. Ubuntu 22.04 est livrée avec PHP 8.1, branche que le projet PHP ne corrige plus. Le correctif existe quand même, produit par l'équipe de sécurité d'Ubuntu. Vous le recevez par une simple mise à jour, mais seulement parce que votre version d'Ubuntu est encore supportée. Les paquets concernés sont php8.1-fpm, php8.1-cli, php8.1-cgi et libapache2-mod-php8.1, selon la façon dont PHP est branché à votre serveur web.
3. Quatre commandes pour vérifier
Les exemples visent Ubuntu 24.04 et le paquet php8.3. Remplacez par php8.1 ou php8.5 et par la version corrigée du tableau pour les autres versions d'Ubuntu.
1. Quels paquets PHP sont installés
dpkg-query -W -f='${Package} ${Version}\n' 'php8*' Cette commande liste chaque paquet PHP avec son numéro complet. Si vous voyez deux versions de PHP, vérifiez-les toutes les deux.
2. Le paquet est-il au niveau du correctif
dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-fpm)" ge 8.3.6-0ubuntu0.24.04.13 && echo "corrigé" || echo "à mettre à jour"Cette comparaison évite de lire les numéros à l'œil. Pour Apache avec mod_php, testez libapache2-mod-php8.3 à la place de php8.3-fpm.
3. Quand le paquet a-t-il été mis à jour, et le service a-t-il suivi
zgrep -h " upgrade php8.3-fpm" /var/log/dpkg.log*
systemctl show php8.3-fpm -p ActiveEnterTimestampLa première ligne donne la date de la mise à jour, la seconde celle du dernier démarrage du service. Si le service a démarré avant la mise à jour, il tourne encore avec l'ancien code.
4. Appliquer et redémarrer
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpmAvec Apache et mod_php, redémarrez apache2 à la place. Un redémarrage coupe les requêtes en cours pendant quelques secondes : choisissez un moment calme pour une boutique en ligne.
4. Les quatre pièges
Une vérification réussie sur le paquet ne garantit pas que le site est protégé. Quatre situations reviennent souvent.
Le service n'a pas redémarré
Un paquet mis à jour ne change pas les processus déjà lancés. PHP-FPM ou Apache continue à servir l'ancien code en mémoire jusqu'à son redémarrage. Comparez la date d'installation du paquet à l'heure de démarrage du service.
Plusieurs versions de PHP cohabitent
Un serveur migré peut garder php8.1 et php8.3 côte à côte. Vérifiez chaque paquet installé, et regardez dans la configuration du serveur web quel socket PHP-FPM sert réellement le site.
Un dépôt tiers fournit PHP
Si PHP vient d'un PPA et non du dépôt Ubuntu, la numérotation suit celle du projet PHP. Comparez alors avec les versions officielles 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, et lancez apt-cache policy pour connaître l'origine du paquet.
Le site tourne dans un conteneur
Mettre à jour l'hôte ne change rien à l'intérieur d'un conteneur. Reconstruisez l'image sur une base corrigée, redéployez, puis contrôlez la version dans le conteneur lui-même.
5. Les versions d'Ubuntu plus anciennes
Les versions 20.04 et 18.04 ne reçoivent plus de mises à jour standard. Les correctifs PHP2Shell y passent par Ubuntu Pro : 7.4.3-4ubuntu2.29+esm5 pour PHP 7.4 sur Ubuntu 20.04, et 7.2.24-0ubuntu0.18.04.17+esm14 pour PHP 7.2 sur Ubuntu 18.04. Pour Ubuntu 16.04 et 14.04, il faut en plus le module Legacy Support de Pro.
Canonical indique que Pro est gratuit pour un usage personnel et jusqu'à cinq machines. Pour une entreprise, vérifiez les conditions avant de vous appuyer sur cette gratuité. Dans tous les cas, ces systèmes sont une dette : plus vous attendez, plus la prochaine faille sera coûteuse à traiter. Le plan de sortie tient en une ligne, migrer vers Ubuntu 24.04, qui embarque PHP 8.3.
6. Une fois corrigé, vérifiez qu'il ne s'est rien passé avant
Les premières tentatives datent du 17 octobre, quatre jours avant le correctif, et des commandes ont réussi sur des serveurs-pièges le 24 octobre. Un serveur mis à jour aujourd'hui a pu être visé entre-temps. Notre guide de détection donne les commandes pour chercher des traces dans les journaux, les fichiers et les processus. Si la question se pose de couper le site le temps de l'enquête, notre article Faut-il couper son site en cas de faille critique ? aide à trancher.
7. Conformité
Le RGPD (article 32) demande des mesures de sécurité adaptées au risque, dont l'application des correctifs de sécurité dans un délai raisonnable. Garder une trace de la date d'application et du contrôle effectué, avec la sortie des commandes, vous permet de le démontrer en cas de contrôle ou d'incident. Pour les entités soumises à NIS2, cette traçabilité fait partie des exigences de gestion des vulnérabilités.
8. Ce que 2LKATIME recommande
Mettez à jour, redémarrez, puis contrôlez avec la comparaison de versions et conservez le résultat. Faites la même chose sur chaque machine, y compris les serveurs de test et les conteneurs que l'on oublie. Nos audits cybersécurité incluent un inventaire des versions installées et une revue de la chaîne de mise à jour.
Les entreprises de Paris, de Lyon ou de Toulouse trouveront les formules sur nos pages tarifs. L'accompagnement se fait aussi à distance partout en France.
FAQ - PHP2Shell sur Ubuntu
Mon Ubuntu 24.04 affiche PHP 8.3.6 : suis-je vulnérable ?
Pas forcément. Ubuntu garde le numéro 8.3.6 et y applique les correctifs de sécurité. Regardez la version du paquet, pas celle de php -v : le serveur est corrigé si php8.3-fpm (ou php8.3-cli) est en 8.3.6-0ubuntu0.24.04.13 ou plus récent.
Dois-je installer la version officielle 8.3.36 à la place ?
Non, ce n'est pas nécessaire. Le paquet Ubuntu corrigé couvre les deux failles, et le maintenir dans le dépôt Ubuntu évite les conflits. Ajoutez un dépôt tiers seulement si votre application exige une version précise de PHP.
Ubuntu 22.04 utilise PHP 8.1, que PHP.net ne corrige plus : suis-je protégé ?
Oui, si le paquet php8.1 est en 8.1.2-1ubuntu2.28 ou plus récent. Canonical a produit lui-même le correctif pour cette branche. Prévoyez malgré tout la migration vers Ubuntu 24.04, car PHP 8.1 ne reçoit plus de mises à jour du projet PHP.
Ma machine tourne sous Ubuntu 20.04 ou 18.04 : que faire ?
Les correctifs de PHP 7.4 (20.04) et de PHP 7.2 (18.04) passent par Ubuntu Pro. Pour 16.04 et 14.04, il faut en plus le module Legacy Support. Canonical indique que Pro est gratuit pour un usage personnel et jusqu'à cinq machines : vérifiez les conditions pour votre cas professionnel.
Mon site tourne dans un conteneur Docker : le correctif Ubuntu s'applique-t-il ?
Seulement si l'image contient les paquets Ubuntu de PHP. Une image PHP officielle de Docker embarque en revanche les versions du projet PHP : il faut la reconstruire avec une version corrigée (8.2.35, 8.3.36, 8.4.27 ou 8.5.12), puis relancer le conteneur.
Sources
Vos serveurs Ubuntu sont-ils vraiment corrigés ?
2LKATIME contrôle vos paquets, vos services et vos conteneurs, puis vous remet un rapport clair avec les actions à mener.