Le 21 octobre 2026, l'équipe qui développe PHP a publié une mise à jour de sécurité urgente. Elle corrige deux failles critiques, notées 9,2 sur 10, que les chercheurs ont baptisées PHP2Shell.
Ce qui rend l'affaire sérieuse, c'est leur portée : elles touchent PHP lui-même, dans toutes ses versions récentes. Voici ce qu'il faut en retenir, sans jargon, et ce que j'ai fait de mon côté.
D'abord : c'est quoi, PHP ?
PHP est un langage de programmation qui tourne sur le serveur. Quand vous ouvrez une page, c'est souvent lui qui la fabrique à la volée : il va chercher les articles, les produits ou votre panier, puis il assemble la page que votre navigateur affiche.
Il est partout. WordPress, PrestaShop, Drupal, Moodle, ou des applications faites sur mesure avec Laravel ou Symfony : tous tournent sur PHP. Une faille dans PHP, c'est donc une faille sous une grande partie des sites web.
PHP2Shell, en image
Pour comprendre, imaginez PHP comme un employé au guichet. Il reçoit les visiteurs un par un, remplit des formulaires pour chacun, puis range son bureau avant de passer au suivant.
Première faille : le bureau qui déborde. Un attaquant envoie une demande construite pour noyer l'employé sous la paperasse, jusqu'à ce que son bureau soit plein. En informatique, on dit que la mémoire est saturée. Pris de court, l'employé fait son rangement de fin de visite sur des formulaires à moitié remplis, comme s'ils étaient complets. Or dans les cases restées vides, l'attaquant s'était arrangé pour glisser ses propres instructions. Et l'employé les exécute.
Deuxième faille : les restes du visiteur précédent. Entre deux visiteurs, l'employé ne vide pas tout à fait son bureau. Certaines informations de la visite précédente traînent encore, alors qu'elles ne devraient plus exister. Le visiteur suivant, s'il sait s'y prendre, peut s'en servir pour lire ce qui reste en mémoire, ou là encore faire exécuter son propre code.
Le nom PHP2Shell résume le résultat : passer de PHP (« PHP ») à un accès direct au serveur (« shell », la ligne de commande).
Pourquoi c'est grave
- Une seule requête suffit. Pas besoin de compte, pas besoin de mot de passe. Un simple envoi bien construit vers le site.
- Votre code n'y est pour rien. La faille est dans PHP lui-même, et elle se déclenche avant même que votre site ne fasse quoi que ce soit. Un site parfaitement bien développé est touché comme les autres.
- C'est une exécution de code à distance. Autrement dit, l'attaquant peut faire tourner ce qu'il veut sur le serveur : voler des données, installer un programme malveillant, s'en servir pour attaquer ailleurs.
- Les attaques ont déjà commencé. Cloudflare indique avoir observé du trafic d'attaque contre ses clients, et Amazon a détecté une tentative d'exploitation quatre jours avant même l'annonce officielle.
Fait notable, ces failles ont été trouvées par des équipes de chercheurs, dont Wiz Research, qui se sont aidées de modèles d'IA pour les découvrir et vérifier les correctifs. Un bon exemple de ce que l'IA change aussi côté sécurité : elle aide à trouver les failles plus vite, mais elle aide aussi ceux qui veulent les exploiter.
Qui est concerné ?
En pratique, tout le monde. Toutes les versions de PHP depuis la 5.4 sont touchées, quelle que soit la façon dont PHP est installé sur le serveur. L'équipe PHP précise que les serveurs Apache qui utilisent le module PHP intégré (mod_php) sont les plus exposés.
Les versions corrigées, publiées le 21 octobre :
| Votre branche | Version corrigée |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 et avant | Plus de mise à jour officielle : migrer vers une version suivie |
Pour PHP 7.4, 8.0 et 8.1, l'équipe a tout de même publié des correctifs minimaux, mais ils s'adressent à ceux qui compilent PHP eux-mêmes. Si votre site tourne sur une de ces versions, c'est le bon moment pour prévoir la migration. Et à noter : PHP 8.2 arrive lui-même en fin de vie le 31 décembre 2026.
Ce que j'ai fait de mon côté
C'est exactement pour ce genre de situation que je surveille les serveurs de mes clients. Mes outils de suivi relèvent, entre autres, la version de PHP qui tourne sur chaque serveur. Quand l'alerte est tombée, je n'ai pas eu à me demander où regarder : la liste était sous mes yeux.
Le constat était simple : toutes les versions que j'utilise étaient concernées. J'ai donc tout mis à jour, redémarré PHP, puis vérifié deux choses : que la nouvelle version tournait bien partout, et que chaque site répondait normalement.
C'est le principe de la maintenance et surveillance : une veille quotidienne des failles, et quand l'une d'elles vous concerne, on agit tout de suite au lieu de le découvrir des semaines plus tard.
Et si vous avez un site en PHP ?
- Vérifiez votre version de PHP. Elle est généralement affichée dans l'espace client de votre hébergeur, ou votre prestataire peut vous la donner.
- Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche. Sur un hébergement mutualisé, c'est souvent l'hébergeur qui s'en charge, mais vérifiez que c'est bien fait.
- Redémarrez PHP (ou le serveur web). Sans ça, l'ancienne version reste chargée en mémoire et continue de tourner.
- Si vous êtes en PHP 8.1 ou avant, il n'y a plus de correctif officiel : la seule vraie solution est de passer à une version suivie.
L'équipe PHP propose quelques réglages pour réduire le risque en attendant, mais elle le dit clairement : ils ne rendent pas l'installation sûre. Seule la mise à jour règle le problème. Pour les détails techniques, l'annonce officielle de PHP et le site des chercheurs font référence.