Comment connaître sa version de PHP (et la comparer au correctif)

Ne vérifiez que des systèmes qui vous appartiennent ou dont vous avez la responsabilité. Cette page et notre vérificateur travaillent uniquement avec les numéros de version que vous saisissez, dans votre navigateur. Rien ici ne teste, n’interroge ni ne scanne un serveur. Site indépendant, non affilié au PHP Group ni à php.net.

Réponse courte

1. Repérez la version de PHP réellement utilisée par votre site : « Santé du site » dans WordPress, l’espace client de votre hébergeur, ou php -v si vous avez un accès SSH (attention, ce dernier ne montre parfois que la ligne de commande, pas le site).
2. Sur Debian, Ubuntu, Red Hat et leurs dérivés, le numéro peut sembler ancien et pourtant être corrigé : la distribution rétroporte parfois les correctifs. Comparez alors la version complète du paquet avec celle indiquée par l’éditeur de la distribution, pas le numéro PHP de php.net.
3. Saisissez le résultat dans le vérificateur pour savoir si vous êtes à jour.

Sur un hébergement mutualisé, c’est l’hébergeur qui installe le correctif sur ses serveurs. Votre rôle : connaître votre version, vérifier l’état de son déploiement dans notre suivi des hébergeurs et, si besoin, changer de version PHP dans votre espace client.

Ce que vous comparez

« php2shell » est le nom donné par Wiz Research à deux failles critiques de PHP, CVE-2026-109618 et CVE-2026-109619. Selon php.net, elles « peuvent permettre une exécution de code à distance sans authentification » (traduction libre) et toute installation PHP qui traite des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed (annonce php.net). Le CERT-FR a publié l’alerte CERTFR-2026-ALE-014 le 21 octobre 2026 ; elle indique que ces failles permettent « une exécution de code arbitraire à distance » et liste comme concernées toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x, ainsi que les versions 8.2 à 8.5 antérieures aux correctifs ci-dessous. Les mesures provisoires évoquées par l’éditeur n’y sont pas qualifiées par le CERT-FR. php.net le dit sans détour : « There are no complete mitigations, updating is the only safe choice » (en clair : aucune mesure d’atténuation ne suffit, seule la mise à jour corrige la faille).

Versions corrigées publiées par php.net (21 octobre 2026) :

Pour un PHP venant de php.net (ou d’une image officielle), tout numéro inférieur à la version corrigée de sa branche est concerné (avis GitHub, fiche NVD). Les paquets de distribution et de panneau font exception : un numéro plus bas peut y être corrigé par rétroportage (voir la méthode 5 et le tableau des panneaux). Le tableau détaillé, avec les paquets des distributions, est sur la page versions corrigées. Pour le contexte, voir ce qu’est php2shell.

Méthode 1 : WordPress, « Santé du site »

C’est le moyen le plus rapide si votre site tourne sous WordPress, sans accès serveur.

1. Connectez-vous à l’administration, puis ouvrez Outils > Santé du site.
2. Allez dans l’onglet Infos (l’intitulé peut varier légèrement selon la version de WordPress) et ouvrez la section Serveur.
3. Relevez la ligne qui indique la version de PHP, souvent Version de PHP (documentation WordPress).

Mettre à jour WordPress, le thème ou les extensions ne corrige pas PHP : les deux CVE visent PHP lui-même (voir l’annonce php.net ci-dessus). Patchstack demande de mettre PHP à jour (8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet corrigé de votre fournisseur) et déconseille les extensions « correctives » non officielles. La suite pour WordPress est dans le guide WordPress.

Méthode 2 : l’espace client de votre hébergeur

Sur un hébergement mutualisé, la version PHP se choisit dans l’espace client. Ce qui est affiché peut se limiter à la branche (par exemple 8.3) sans le numéro complet : si le numéro manque, utilisez la méthode 3 ou demandez-le à l’hébergeur.

Nous n’avons pas vérifié de chemin de menu précis pour les hébergeurs de notre liste (OVHcloud compris) ; cherchez « version PHP » dans l’aide de votre hébergeur ou dans la configuration de votre hébergement. Voici ce que disent leurs pages officielles (état vérifié le 22 octobre 2026, ces informations évoluent vite) :

« Aucune annonce trouvée » ne veut pas dire « non corrigé » : cela signifie seulement que nous n’avons rien lu à ce sujet. Interrogez l’hébergeur si vous avez un doute. Le détail est dans le suivi des hébergeurs et le guide hébergement.

Si votre hébergement utilise un panneau de contrôle classique :

Méthode 3 : un fichier de test, supprimé aussitôt

Si le panneau n’affiche pas le numéro complet, un petit fichier PHP donne la version servie par le site lui-même. Plutôt qu’une page phpinfo() complète, utilisez cette seule ligne : elle n’affiche que la version et le type d’exécution (fpm-fcgi, apache2handler, litespeed, etc., selon le manuel PHP).

Créez un fichier au nom difficile à deviner, par exemple v-7f3a9c21.php, contenant :

<?php header("Content-Type: text/plain"); echo PHP_VERSION, " ", php_sapi_name(), PHP_EOL;

Envoyez-le par FTP ou par le gestionnaire de fichiers dans le dossier de votre site, ouvrez https://votre-site.fr/v-7f3a9c21.php dans le navigateur, notez le résultat, puis supprimez le fichier immédiatement. Avec SSH, la même chose en ligne de commande :

f="v-$(openssl rand -hex 8).php"
printf '<?php header("Content-Type: text/plain"); echo PHP_VERSION, " ", php_sapi_name(), PHP_EOL;\n' | sudo tee "/var/www/html/$f" >/dev/null
curl -s "https://votre-site.fr/$f"
sudo rm -f "/var/www/html/$f"

Adaptez le dossier racine et le domaine. Si vous préférez phpinfo();, ne lisez que PHP Version et Server API, puis supprimez le fichier sans attendre : phpinfo() affiche des chemins, des réglages et des variables d’environnement qui n’ont rien à faire sur une adresse publique (manuel PHP).

Méthode 4 : en ligne de commande (SSH, serveur ou VPS)

php -v
which -a php
php -r 'echo PHP_VERSION, " ", php_sapi_name(), PHP_EOL;'

La première ligne de php -v donne la version ; (cli) indique que c’est la ligne de commande (manuel PHP). Ce n’est que le PHP en ligne de commande. Un serveur peut avoir plusieurs versions installées, et celle de votre site (PHP-FPM, Apache, LiteSpeed) n’est pas forcément celle de php dans votre terminal. Interrogez aussi le côté web :

php-fpm8.3 -v                  # Debian/Ubuntu : le nom du binaire contient la version
php-fpm -v                     # famille Red Hat et autres
apache2ctl -M | grep -i php    # Apache avec mod_php (httpd -M chez Red Hat)

Méthode 5 : la version du paquet de la distribution

Sur Ubuntu, Debian et la famille Red Hat, le numéro PHP d’origine peut rester le même (8.3.6 sur Ubuntu 24.04, par exemple) alors que le correctif est rétroporté : seul le suffixe change. Sur Alpine, le paquet corrigé porte la version amont (8.4.27-r0). Dans tous les cas, lisez la version complète du paquet.

Debian et Ubuntu :

dpkg -l | grep -E '^ii +php'
apt policy php8.3-cli                      # lisez « Installed », pas « Candidate »
apt changelog php8.3-cli | grep -m3 -E 'CVE-2026-10961[89]'

Famille Red Hat (RHEL, AlmaLinux, Rocky Linux, Oracle Linux, Amazon Linux) :

rpm -qa | grep -i '^php'
rpm -q --changelog php-cli | grep -m3 -E 'CVE-2026-10961[89]'

Alpine :

apk list -I | grep -i php
apk version php84

Une ligne de journal qui cite la CVE est un bon indice que le correctif est présent. L’absence de résultat ne prouve pas que le paquet est vulnérable : comparez avec la valeur de l’éditeur.

Les dépôts tiers (PPA d’Ondřej Surý, sury.org) et les autres versions d’Ubuntu et Debian sont dans le tableau des versions corrigées. Le dépôt RPM de Remi (tiers, maintenu par des bénévoles) propose désormais des builds datés du 21 octobre pour Enterprise Linux 8, 9 et 10 en PHP 8.2 à 8.5, par exemple 8.3.36-1.el9.remi ; Remi ne cite pas les CVE, mais ces numéros sont les versions amont corrigées. Le jour de la sortie, php.net indiquait que ce dépôt n’aurait pas de mise à jour et recommandait les paquets de la distribution ou une compilation depuis les sources (php.net).

Docker

Une étiquette d’image indique ce que vous avez téléchargé, pas ce qui tourne. Vérifiez dans le conteneur :

docker ps --format '{{.Names}}  {{.Image}}'
docker exec <conteneur> php -v

Une étiquette mobile comme php:8.4-fpm ne change qu’après un nouveau téléchargement. Mettez à jour l’image puis recréez le conteneur (docker compose pull && docker compose up -d) : un simple redémarrage garde l’ancienne image. Lors de notre relevé, les images officielles php:8.5, php:8.4, php:8.3 et php:8.2 étaient publiées en 8.5.12, 8.4.27, 8.3.36 et 8.2.35 : téléchargez-les de nouveau, puis confirmez avec php -v.

Que faire du résultat

Après une mise à jour, redémarrez le service PHP pour que les processus chargent le nouveau code, puis revérifiez :

sudo systemctl restart php8.3-fpm      # ou php-fpm, ou apache2 / httpd
php -v

Changer de branche (par exemple 8.1 vers 8.3) peut casser des extensions ou des modules : faites une sauvegarde complète ou un instantané avant. Sur un hébergement mutualisé, faites-la depuis votre espace client avant de changer de version PHP.

Étape finale : saisir le résultat dans le vérificateur

Ouvrez le vérificateur, choisissez votre plateforme et saisissez la version exactement comme affichée : le numéro PHP pour php.net, un panneau ou Docker, ou la chaîne complète du paquet (par exemple 8.3.6-0ubuntu0.24.04.13) pour une distribution. Il compare ce que vous tapez, dans votre navigateur ; il ne regarde pas votre serveur. Un pare-feu applicatif (WAF) devant votre site ne remplace pas la mise à jour de PHP : Cloudflare lui-même recommande de corriger PHP malgré ses règles.

Vous préférez ne pas démêler tout cela vous-même ? Nous proposons un plan de correctifs personnalisé à 49 $ US : des étapes écrites pour votre configuration exacte, envoyées par e-mail sous 24 h ; nous ne nous connectons jamais à votre serveur, c’est vous qui appliquez les étapes. Voir le service de correction.