<?php Vérification de sécurité PHP indépendante
Votre PHP est-il concerné par PHP2Shell ?
Deux failles critiques dans PHP lui-même permettent l’exécution de code à distance. Elles ont été corrigées le 21 octobre 2026. Vérifiez ce qu’un site révèle de sa version de PHP, ou collez une chaîne de version — puis voyez précisément ce qu’il faut faire.
- Passive : une requête ordinaire, aucun exploit
- Gratuit, sans inscription, sans publicité
- Fondé sur php.net et les avis officiels
2Vérifier une version
Analysé dans votre navigateur — rien ne nous est envoyé. Une version par ligne, 20 au maximum.
01 · php.net · 2026-10-23
Versions corrigées
| Branche | Corrigé dans | État de la branche |
|---|---|---|
| PHP 8.5 | 8.5.12 | Support actif |
| PHP 8.4 | 8.4.27 | Support actif |
| PHP 8.3 | 8.3.36 | Correctifs de sécurité uniquement |
| PHP 8.2 | 8.2.35 | Correctifs de sécurité uniquement — fin de vie le 31 déc. 2026 |
| PHP 8.1 · 8.0 · 7.x · 5.x | Aucune version officielle | Fin de vie — aucune version du projet PHP |
Source : avis de sécurité php.net, 21 octobre 2026. Dernière vérification le 2026-10-23.
Qu’est-ce que PHP2Shell ?
PHP2Shell est le nom donné par des chercheurs à deux vulnérabilités du moteur PHP : CVE-2026-109618 (corruption de mémoire lorsque PHP manque de mémoire pendant l’analyse d’une requête) et CVE-2026-109619 (état interne qui subsiste d’une requête à la suivante sur le même worker). Toutes deux sont notées 9.2 selon CVSS v4.0.
Un attaquant non authentifié peut exécuter du code sur le serveur ou lire la mémoire du processus PHP — y compris des mots de passe, jetons de session, clés d’API et certificats appartenant à d’autres requêtes — sans exécuter le moindre code. Selon php.net, elles concernent PHP lorsqu’il traite des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les chercheurs ont démontré des attaques contre WordPress, Drupal et Joomla, mais aucune application particulière n’est nécessaire : même une simple page « Hello World » sur un PHP concerné est exposée.
Que faire maintenant
- Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — ou vers le paquet corrigé de votre distribution.
- Redémarrez tous les processus PHP : PHP-FPM, Apache, workers de file d’attente, conteneurs. Une mise à jour n’est pas active avant cela.
- Vérifiez chaque PHP présent sur le serveur — les panneaux de contrôle installent souvent plusieurs versions côte à côte.
02 · shell
Vérifier sur le serveur lui-même
Une vérification de site ne voit que ce que le serveur choisit de révéler. Sur le serveur, ces commandes donnent la vraie réponse :
# version du PHP par défaut
php -v
# autres versions de PHP installées par des panneaux ou des paquets
ls -d /usr/bin/php* /usr/sbin/php-fpm* /opt/alt/php*/usr/bin/php /opt/cpanel/ea-php*/root/usr/bin/php /opt/plesk/php/*/bin/php 2>/dev/null
# paramètres liés aux mesures d’atténuation partielles
php -i | grep -E 'session.upload_progress.enabled|post_max_size|memory_limit|fatal_error_backtraces'
# ce que votre site révèle aux visiteurs
curl -sI https://votre-site.fr/ | grep -i -E '^(x-powered-by|server):'03 · FAQ
Questions fréquentes
Quelles versions de PHP sont concernées ?
Toutes les versions antérieures à 8.5.12, 8.4.27, 8.3.36 et 8.2.35 dans les branches prises en charge. PHP 8.1 et les versions plus anciennes sont en fin de vie et ne reçoivent aucune version du projet PHP ; considérez-les comme concernées, sauf si votre éditeur confirme un correctif rétroporté.
Mon site n’affiche pas de version de PHP. Suis-je protégé ?
Pas nécessairement. Masquer la version (expose_php = Off) est une bonne pratique, mais ne corrige rien. Vérifiez sur le serveur avec php -v ou interrogez votre fournisseur.
L’outil affiche une ancienne version, mais mon hébergeur affirme qu’elle est corrigée. Qui a raison ?
Peut-être les deux. Les distributions Linux comme Debian, Ubuntu et RHEL rétroportent souvent les correctifs de sécurité sans changer le numéro de version. Demandez à votre hébergeur quel build de paquet est installé et si son changelog mentionne CVE-2026-109618 et CVE-2026-109619.
WordPress, Laravel ou mon CMS sont-ils concernés ?
Les failles se trouvent dans PHP lui-même : toute application qui tourne sur un PHP concerné est donc exposée. Les chercheurs ont démontré des attaques sans authentification contre WordPress, Drupal et Joomla, mais ce n’étaient que des exemples — même une simple page « Hello World » suffit. Mettre à jour WordPress ou les extensions ne corrige rien ; c’est PHP qui doit être mis à jour.
Des données peuvent-elles fuiter même si aucun code n’a été exécuté ?
Oui. CVE-2026-109619 peut divulguer la mémoire du processus PHP — mots de passe, jetons de session, clés d’API et certificats provenant d’autres requêtes — sans que l’attaquant exécute de code. De telles fuites ne laissent aucun fichier et sont difficiles à détecter : changez donc les secrets de tout site ayant fonctionné avec une version concernée sur Internet.