Faille PHP2Shell : votre site est-il protégé ? La marche à suivre.

L’essentiel en 30 secondes

• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• PHP 8.1 et plus ancien : aucune version officielle corrigée. Il faut un correctif de votre hébergeur ou de votre distribution, ou migrer.
• Aucune solution de contournement complète : seule la mise à jour règle le problème.
• WordPress, PrestaShop et les autres sont concernés indirectement : ce qui compte, c’est la version de PHP du serveur, pas celle de votre CMS.

La marche à suivre tient en trois temps : vérifier votre version, mettre à jour, puis contrôler qu’il ne s’est rien passé.

Pour comprendre sans jargon : le restaurant

Imaginez votre site comme un restaurant.

La faille n’est pas dans la carte, elle est dans le règlement de la cuisine. Quand la cuisine est débordée, le cuisinier peut laisser traîner un bon de commande à moitié rempli, ou réutiliser celui du client précédent. Un client malin glisse alors une fausse consigne, que le cuisinier exécute comme si elle venait de la direction. Et il n’a pas besoin de réservation : n’importe qui peut passer commande.

• Changer la carte (mettre à jour WordPress ou un plugin) ne change rien : le problème est dans la cuisine.
• Il faut que la cuisine applique le nouveau règlement : c’est la mise à jour de PHP, par vous ou par votre hébergeur.
• Les mesures provisoires reviennent à fermer le guichet des colis : une des façons de glisser une consigne disparaît, pas toutes.
• Après la mise à jour, on vérifie si quelqu’un est entré : des objets qui n’ont rien à faire en cuisine (des fichiers inconnus), un nouveau badge du personnel (un compte administrateur inconnu). Si oui, on change les clés.

L’image est simplifiée, mais la marche à suivre qui suit, elle, est exacte.

Ce qui s’est passé

PHP a publié le 21 octobre 2026 une version corrigée pour chacune de ses branches encore suivies. Les deux failles touchent le moteur de PHP lui-même, pas un plugin :

• CVE-2026-109618 : quand le serveur manque de mémoire en pleine requête, PHP peut se retrouver avec des données internes à moitié initialisées, puis les traiter comme valides. Le traitement des envois de fichiers (multipart) est cité comme déclencheur.
• CVE-2026-109619 : un état interne propre à une requête peut survivre à la libération de sa mémoire, puis être réutilisé par la requête suivante servie par le même processus. Deux cas sont confirmés : la progression d’envoi de session (session.upload_progress) et, en PHP 8.5, le suivi des erreurs fatales.

Les analyses publiées divergent sur certains détails techniques. Je m’en tiens à ce sur quoi elles convergent, et je le signale quand un point est incertain.

Quel est le risque réel ?

• Le plus exposé : PHP en module Apache (mod_php). Une exploitation y a été démontrée.
• Avec PHP-FPM (le cas de la plupart des hébergements récents) : la voie d’attaque est moins claire, et dépend de l’application. Ne comptez pas là-dessus : une voie confirmée passe par la progression d’envoi de session.
• Exploitation dans la nature : les rapports se contredisent. Selon l’analyse de Brandefense, la CISA a ajouté les deux failles à son catalogue des vulnérabilités exploitées le 26 octobre ; d’autres sociétés n’ont observé que des tentatives de sondage, et l’une d’elles a retiré un rapport d’attaque. Des preuves de concept circulent publiquement.

Conclusion pratique : pas de panique, mais à traiter comme urgent. Un site qui reste sur une version non corrigée sera tôt ou tard sondé.

Quelles versions sont corrigées ?

Attention au numéro de version : sur Debian et Ubuntu, le correctif est souvent ajouté à une version portant un ancien numéro. Un « 8.4.26 » peut donc être corrigé, et un « 8.4.27 » jamais installé tel quel. Le journal des modifications du paquet fait foi (voir ci-dessous).

Comment vérifier votre version

Hébergement mutualisé

Dans votre espace client, rubrique « Version de PHP » ou « Configuration PHP ». Notez la branche (8.2, 8.3, 8.4, 8.5…), puis demandez à l’hébergeur s’il a appliqué les correctifs du 21 octobre. Sur un mutualisé, c’est lui qui met PHP à jour, pas vous.

Serveur à vous (VPS, dédié)

php -v
php-fpm8.4 -v        # le nom varie selon la distribution
apt changelog php8.4-fpm | grep -i -E "CVE-2026-10961[89]"

Le dernier test cherche les deux failles dans l’historique du paquet : s’il affiche des lignes, le correctif est présent. La version « CLI » (php -v) peut différer de celle qu’utilise le site web.

Sur WordPress

Outils, Santé du site, onglet Info, section Serveur : la version de PHP s’y affiche. Mettre à jour WordPress lui-même ne corrige pas cette faille.

Que faire, selon votre situation

Sur un serveur Debian ou Ubuntu, la mise à jour se fait avec la procédure habituelle, puis un redémarrage du service :

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.4-fpm     # adapter à votre version

Si vous ne pouvez pas mettre à jour aujourd’hui

Ces mesures réduisent certaines voies d’attaque, aucune ne remplace la mise à jour. À poser dans le php.ini ou dans la configuration du pool PHP-FPM, puis à redémarrer (un .user.ini ou un ini_set() arrive parfois trop tard, d’après les analyses) :

; mesures partielles, en attendant la mise à jour
session.upload_progress.enabled = 0
fatal_error_backtraces = 0       ; PHP 8.5 uniquement
post_max_size = 8M               ; si vous n'envoyez pas de gros fichiers

Pour un site qui n’a besoin d’aucun envoi de fichier, on peut aussi refuser ce type de requête avant qu’elle n’atteigne PHP (Apache) :

<If "%{HTTP:Content-Type} =~ m#multipart/form-data#i">
    Require all denied
</If>

D’autres réglages (notamment sur la mémoire) sont cités dans certaines analyses, avec des effets de bord. Je ne les recommande pas sans un audit du serveur.

Après la mise à jour : chercher d’éventuelles traces

Entre le 21 octobre et le jour de votre mise à jour, un site non corrigé a pu être sondé, voire visité. Un contrôle prend une heure et rassure. Voici ce que je regarde :

• Les journaux d’accès : des rafales de requêtes POST envoyant des fichiers (multipart) vers la page d’accueil ou des pages qui n’en reçoivent jamais, à partir du 21 octobre.
• Du code PHP là où il ne devrait pas y en avoir : le dossier des fichiers envoyés ne doit jamais contenir de .php.
• Des fichiers PHP nouveaux ou modifiés depuis le 20 octobre.
• De nouveaux comptes administrateur, des tâches planifiées inconnues, des connexions sortantes inhabituelles.

# fichiers PHP modifiés depuis le 20 octobre (hors cache)
find /chemin/du/site -name '*.php' -newermt '2026-10-20' -not -path '*/cache/*' | head -50

# WordPress : PHP dans les envois, comptes admin, intégrité du cœur et des extensions
find wp-content/uploads -name '*.php'
wp user list --role=administrator --fields=ID,user_login,user_registered
wp core verify-checksums
wp plugin verify-checksums --all

Un fichier index.php vide dans un dossier est souvent normal : certains plugins en créent pour empêcher le listing du dossier. C’est un fichier qui contient du code, ou un nom étrange, qui doit alerter.

En cas de doute : restaurer une sauvegarde antérieure au 21 octobre sur une copie, changer les mots de passe (administrateurs, base de données, FTP), et régénérer les clés de sécurité de wp-config.php sur WordPress.

Sources et réserves

Cette page a été vérifiée le 30 octobre 2026. La référence officielle est l’annonce de sortie sur php.net, à consulter pour les numéros de version exacts. J’ai aussi lu les analyses de Brandefense, Snyk et Patchstack.

Les sources divergent sur le niveau d’exploitation réel et sur certains détails techniques ; la situation évolue vite. Sur les serveurs que j’administre, j’ai posé des protections provisoires le jour de la publication, puis installé les paquets corrigés dans les jours suivants. Ce n’est pas un avis juridique ni un audit de votre site.

Questions fréquentes