🛡️ Faille critique dans PHP (PHP2Shell) : comment savoir si votre site est concerné et le protéger

🌐 Français · English · العربية

Deux failles critiques de PHP permettent d'exécuter du code sur un serveur sans aucun identifiant. Voici comment vérifier en quelques minutes si votre site est concerné, le corriger proprement, et ne plus jamais être pris de court par la prochaine.

Mis à jour : 22 octobre 2026

En bref

Le 21 octobre 2026, PHP a corrigé deux failles critiques (CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ») qui permettent d'exécuter du code à distance sans authentification.
Versions corrigées : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. En dessous, vous êtes concerné.
Tous les sites qui exécutent PHP sont visés : WordPress, WooCommerce, Prestashop, Laravel, sites sur mesure.
Mettre à jour ne suffit pas toujours : il faut aussi redémarrer PHP, sinon l'ancienne version reste en mémoire.
Sur un serveur que j'administre, la correction a été faite le lendemain de la publication et chaque site vérifié un par un. Ce guide reprend exactement cette méthode.

1. Ce qui s'est passé

Le 21 octobre 2026, l'équipe de PHP a publié un avis de sécurité titré « vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant ». Il corrige deux failles distinctes, chacune notée 9,2 sur 10 (CVSS v4) :

Faille	Nature (sans détail technique)	Avis officiel
CVE-2026-109618	Corruption de données internes quand PHP manque de mémoire	GHSA-w8hw-w9fx-j79w
CVE-2026-109619	Un état interne qui survit d'une requête à la suivante	GHSA-6wmf-4rv5-p3rp

Ce qu'elles permettent : dans certaines conditions, une simple requête envoyée à votre site, sans compte ni mot de passe, peut faire exécuter du code par le serveur, avec les droits du site. En clair : prise de contrôle du site, vol de la base de données, installation de pages malveillantes.

Qui est exposé : selon l'avis officiel, toutes les installations PHP qui servent des pages web, quel que soit le mode : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. L'équipe de PHP considère le risque le plus élevé avec mod_php.

Pourquoi c'est urgent : les identifiants des failles ont fuité sur un forum la veille de la publication officielle, avant la fin de l'embargo. Une fois qu'une faille aussi grave est publique et que le correctif est disponible, d'autres peuvent étudier les changements et chercher à les exploiter. Mieux vaut considérer que les robots qui scannent Internet à la recherche de serveurs non corrigés vont s'y intéresser rapidement.

Les versions corrigées :

PHP 8.5 → 8.5.12
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35

Et les versions plus anciennes ? PHP 8.1 et les versions précédentes ne reçoivent plus de mises à jour officielles. L'équipe de PHP a tout de même fourni des correctifs minimaux pour 7.4, 8.0 et 8.1 aux distributions et aux éditeurs qui assurent un support étendu. Concrètement, si votre serveur utilise le PHP fourni par sa distribution Linux (AlmaLinux, Rocky, Red Hat, Debian, Ubuntu…), c'est la mise à jour du paquet de la distribution qui compte, pas le numéro de version affiché. Par exemple, AlmaLinux a publié dès le 21 octobre une mise à jour de son paquet PHP 8.0 qui corrige les deux failles, alors que le numéro « 8.0.30 » ne change pas.

À retenir. PHP 8.2 arrive en fin de vie le 31 décembre 2026. Si vous êtes encore en 8.2 ou plus ancien, cette faille est le bon moment pour planifier le passage à 8.3 ou plus récent.

2. Suis-je concerné ?

La réponse dépend de la façon dont votre site est hébergé. Trouvez votre cas.

Hébergement mutualisé (cPanel, Plesk, hPanel…)

C'est le cas le plus fréquent pour les petits sites. Vous ne gérez pas le serveur : c'est votre hébergeur qui installe les correctifs de PHP. Votre rôle :

Vérifiez la version choisie pour votre site dans le panneau : « Select PHP Version » ou « MultiPHP Manager » sur cPanel, « Paramètres PHP » sur Plesk, « Configuration PHP » sur hPanel. Notez la branche (8.1, 8.2, 8.3…).
Si vous êtes en 8.1 ou plus ancien, passez à 8.3 ou plus récent, après avoir vérifié que votre thème et vos extensions le supportent (voir plus bas).
Écrivez au support de votre hébergeur : « Avez-vous appliqué les correctifs PHP du 21 octobre 2026 (CVE-2026-109618 et CVE-2026-109619) sur mon serveur ? ». Un hébergeur sérieux répond clairement et rapidement. S'il ne sait pas de quoi vous parlez, c'est une information précieuse sur sa fiabilité.

Site WordPress

Dans votre tableau de bord : Outils → Santé du site → Infos → Serveur. La ligne « Version de PHP » indique la version utilisée par votre site. Sur un hébergement mutualisé, ce numéro ne dit pas toujours si le correctif est appliqué (voir l'encadré sur les distributions plus haut) : en cas de doute, posez la question à l'hébergeur.

Avant de changer de branche de PHP, vérifiez que votre thème et vos extensions sont à jour, et faites une sauvegarde. Les extensions abandonnées depuis des années sont souvent celles qui bloquent un passage à une version récente.

Serveur VPS ou dédié

Vous êtes l'administrateur : c'est à vous d'agir. Le piège principal est qu'un serveur peut avoir plusieurs versions de PHP installées en même temps, et que la commande php -v n'indique que celle de la ligne de commande, pas forcément celle qui sert vos sites.

Vérifiez dans l'ordre :

1. Les versions installées :

# AlmaLinux, Rocky, Red Hat
rpm -qa | grep -E '^php[0-9]*(-php)?-(common|fpm)'

# Debian, Ubuntu
dpkg -l | grep -E 'php[0-9.]*-(common|fpm)'

2. Les services PHP-FPM actifs (ce sont eux qui exécutent vos sites) :

systemctl list-units --type=service --state=running | grep -i php

3. Quelle version sert chaque site : regardez dans la configuration de votre serveur web vers quel « pool » PHP-FPM chaque site envoie ses requêtes, puis à quelle version appartient ce pool. Sur un panneau comme Virtualmin, cPanel ou Plesk, l'information est aussi affichée dans les réglages de chaque domaine.

4. Les mises à jour disponibles :

# AlmaLinux, Rocky, Red Hat
dnf check-update 'php*'

# Debian, Ubuntu
apt update && apt list --upgradable | grep -i php

Si une mise à jour de PHP est proposée, considérez-vous comme concerné jusqu'à preuve du contraire.

Le réflexe à proscrire : la page phpinfo publique

Pour connaître leur version, beaucoup créent un fichier info.php contenant phpinfo(). Ne le laissez jamais en ligne. Cette page affiche la version exacte, les extensions, les chemins du serveur et une partie de la configuration : c'est une carte précieuse pour un attaquant. Si vous devez l'utiliser, faites-le quelques secondes, puis supprimez le fichier. La page « Santé du site » de WordPress ou la ligne de commande sont de bien meilleures options.

3. Corriger

Mettre à jour

Sur un VPS, l'opération tient en une commande :

# AlmaLinux, Rocky, Red Hat
dnf upgrade 'php*'

# Debian, Ubuntu
apt update && apt install --only-upgrade 'php*'

Avant, si vous gérez des sites importants, faites une sauvegarde (base de données et fichiers). Une mise à jour de correctif à l'intérieur d'une même branche (par exemple 8.3.35 vers 8.3.36) casse très rarement quelque chose, mais une sauvegarde ne coûte que quelques minutes.

Redémarrer PHP : l'étape que tout le monde oublie

Installer les nouveaux paquets ne remplace pas le PHP qui tourne déjà : les processus PHP-FPM en cours d'exécution gardent l'ancienne version, vulnérable, en mémoire, parfois pendant des semaines. Il faut redémarrer chaque service PHP-FPM :

systemctl restart php-fpm            # le nom exact dépend de votre installation
systemctl restart php8.3-fpm         # Debian, Ubuntu

Avec mod_php, c'est Apache qu'il faut redémarrer.

Puis vérifiez que les processus en cours ont bien démarré après la mise à jour :

ps -eo pid,lstart,cmd | grep "php-fpm: master"

L'heure de démarrage doit être postérieure à la mise à jour. Sur les systèmes Red Hat et dérivés, la commande dnf needs-restarting -s liste aussi les services qui utilisent encore d'anciennes versions.

Vérifier chaque site

Ne vous contentez pas de la page d'accueil, qui est souvent servie depuis un cache. Pour chaque site, testez :

la page d'accueil ;
une page qui exécute vraiment PHP : la connexion à l'administration (/wp-login.php pour WordPress), le panier ou la page de commande d'une boutique ;
l'absence d'erreur dans le journal d'erreurs du site.

Sur un serveur que j'administre, j'ai comparé pour chaque site la réponse avant et après la mise à jour : tout était identique, et aucune erreur n'est apparue dans les journaux.

4. Atténuer si vous ne pouvez pas mettre à jour tout de suite

L'avis officiel est clair : seule la mise à jour corrige complètement ces failles. Les mesures ci-dessous réduisent certains chemins d'attaque, elles ne rendent pas un serveur sûr. Elles servent à tenir quelques heures, le temps d'organiser la mise à jour.

Désactiver le suivi de progression des envois (pour CVE-2026-109619) : dans le php.ini ou la configuration du pool PHP-FPM, session.upload_progress.enabled = 0, puis redémarrez tous les processus PHP. L'avis précise de ne pas compter sur ini_set() ni sur un fichier .user.ini, qui s'appliquent trop tard. Cette fonction est rarement utilisée : l'équipe de PHP conseille même de la laisser désactivée après la mise à jour si vous n'en avez pas besoin.
Limiter la taille des requêtes (pour CVE-2026-109618) : une valeur basse pour post_max_size, et des limites de taille de requête au niveau du serveur web ou du proxy.
Sur PHP 8.5 uniquement : fatal_error_backtraces = 0, puis redémarrage des processus.

L'avis officiel mentionne aussi d'autres réglages liés à la mémoire, mais ils ont des effets de bord importants : ne les appliquez pas sans bien comprendre leurs conséquences sur votre serveur.

5. Ai-je été compromis ?

Si votre serveur a été corrigé rapidement, le risque est faible. Mais si vous êtes resté plusieurs jours avec une version vulnérable, prenez dix minutes pour vérifier quelques signes, sans paniquer.

Fichiers PHP récents et inattendus, surtout dans les dossiers d'images ou de cache :

find /chemin/du/site -name '*.php' -newermt '2026-10-20' -not -path '*/cache/*'

Sur un WordPress, un fichier PHP dans wp-content/uploads est presque toujours suspect.

Comptes administrateurs inconnus : dans WordPress, Utilisateurs → filtrer par rôle Administrateur.
Tâches planifiées inconnues : crontab -l pour chaque utilisateur du site, et le dossier /etc/cron.d.
Journaux : des requêtes en rafale vers des adresses étranges, des erreurs PHP inhabituelles autour du 20 au 22 octobre.
Comportement du site : redirections vers des sites de jeux ou de pharmacie, pages en langue étrangère indexées par Google, alertes de sécurité de votre hébergeur.

Si vous trouvez quelque chose : ne vous contentez pas de supprimer le fichier. Mettez le site en maintenance, changez tous les mots de passe (administration, base de données, FTP, hébergement), restaurez une sauvegarde saine antérieure à l'incident si vous en avez une, mettez tout à jour, puis surveillez. Si vous n'êtes pas sûr de vous, faites appel à un professionnel : un nettoyage partiel laisse souvent une porte dérobée.

6. Ne plus être pris de court

Les mises à jour de sécurité automatiques

Sur un serveur, activez l'installation automatique des correctifs de sécurité :

AlmaLinux, Rocky, Red Hat : dnf-automatic, configuré pour appliquer les mises à jour de sécurité ;
Debian, Ubuntu : unattended-upgrades.

Le piège que j'ai découvert

Sur un serveur que j'administre, PHP ne vient pas de la distribution mais d'un dépôt tiers très répandu (le dépôt de Remi Collet), qui permet d'installer plusieurs versions récentes de PHP. Ce dépôt publie ses correctifs rapidement, mais ne les étiquette pas comme « mises à jour de sécurité » dans les métadonnées que lisent les outils automatiques. Résultat : un réglage « installer seulement les mises à jour de sécurité » aurait ignoré la correction de PHP2Shell, alors que le serveur avait l'air protégé.

La solution que j'ai mise en place, et que je recommande :

une tâche nocturne qui applique les correctifs de sécurité de la distribution et, explicitement, les mises à jour des paquets PHP (dnf upgrade --security puis dnf upgrade 'php*') ;
le redémarrage automatique de PHP-FPM quand PHP a été mis à jour ;
un contrôle de chaque site après l'opération, avec une alerte si l'un d'eux ne répond plus.

Les mises à jour de correctif à l'intérieur d'une même branche de PHP sont conçues pour ne rien casser. Les automatiser est raisonnable ; les changements de branche (8.3 vers 8.4, par exemple), eux, restent une décision à prendre à la main, après des tests.

Surveiller les annonces

l'actualité de php.net, où les avis de sécurité sont publiés ;
la liste des versions supportées, pour anticiper les fins de vie ;
les annonces de sécurité de votre distribution Linux ou de votre hébergeur.

Checklist

[ ] Je connais la version de PHP qui sert chacun de mes sites, pas seulement celle de la ligne de commande.
[ ] Mes sites tournent sur 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou plus récent, ou sur un paquet de distribution qui a reçu le correctif.
[ ] PHP-FPM (ou Apache avec mod_php) a été redémarré après la mise à jour, et j'ai vérifié l'heure de démarrage des processus.
[ ] J'ai testé une page qui exécute vraiment PHP sur chaque site.
[ ] Aucun fichier phpinfo() n'est accessible en ligne.
[ ] Si session.upload_progress ne me sert pas, il est désactivé.
[ ] J'ai vérifié l'absence de fichiers PHP suspects et de comptes administrateurs inconnus.
[ ] Les mises à jour de sécurité sont automatiques, paquets PHP compris s'ils viennent d'un dépôt tiers.
[ ] Si je suis encore en PHP 8.2 ou plus ancien, j'ai planifié le passage à une branche supportée.

FAQ

Mon site WordPress est-il concerné même s'il est à jour ?

Oui, potentiellement. La faille est dans PHP, le langage qui fait tourner WordPress, pas dans WordPress lui-même ni dans vos extensions. Un WordPress parfaitement à jour sur un PHP vulnérable reste exposé.

Mon hébergeur s'en occupe-t-il automatiquement ?

Sur un hébergement mutualisé, c'est son rôle, et les hébergeurs sérieux appliquent ce type de correctif en priorité. Mais vérifiez : demandez-lui explicitement s'il a appliqué les correctifs du 21 octobre 2026. Sur un VPS ou un serveur dédié, personne ne le fera à votre place.

J'ai mis à jour PHP, est-ce suffisant ?

Seulement si PHP a été redémarré ensuite. Tant que les processus PHP-FPM (ou Apache avec mod_php) n'ont pas redémarré, l'ancienne version vulnérable continue de servir vos pages.

`php -v` affiche une version ancienne, suis-je forcément vulnérable ?

Pas forcément. D'abord, cette commande montre la version de la ligne de commande, qui n'est pas toujours celle qui sert vos sites. Ensuite, les distributions Linux corrigent souvent leurs paquets sans changer le numéro de version : c'est la date et le détail du paquet qui comptent.

Désactiver session.upload_progress me protège-t-il ?

En partie seulement. L'avis officiel indique que cela bloque les chemins d'attaque confirmés liés aux sessions pour l'une des deux failles, pas les autres variantes, et rien pour la seconde faille. C'est une mesure d'attente, pas une correction.

Je suis encore en PHP 7.4 ou 8.0, que faire ?

Ces versions ne reçoivent plus de mises à jour officielles. Si votre PHP vient d'une distribution qui assure un support étendu, vérifiez que son paquet a reçu le correctif. Sinon, la vraie solution est de passer à une version supportée : c'est un chantier à prévoir, car d'anciens thèmes ou extensions peuvent nécessiter des adaptations.

Comment savoir si on a tenté d'exploiter la faille sur mon site ?

Il n'existe pas de signature simple et universelle. Regardez les signes de compromission décrits plus haut (fichiers récents, comptes inconnus, tâches planifiées, comportement anormal). En cas de doute sérieux, faites analyser le serveur par un professionnel.

Sources

Besoin d'aide ?

Je peux vérifier et corriger votre serveur ou votre hébergement, mettre en place des mises à jour de sécurité automatiques fiables et surveiller vos sites au quotidien. Voir le service maintenance et hébergement ou me contacter. Pour un premier diagnostic gratuit de votre domaine, essayez le bilan de santé d'un domaine.

← Tous les guides