PHP2Shell : que faire maintenant sur votre site WordPress

PHP2Shell désigne deux vulnérabilités critiques dans PHP lui-même, rendues publiques le 21 octobre 2026 et notées 9,2 sur l’échelle CVSS. Sur un environnement PHP non corrigé, un attaquant sans compte peut exécuter du code sur le serveur ou lire une mémoire qui contient des mots de passe, des jetons de session et des clés d’API. Les chercheurs en ont fait la démonstration sur des installations WordPress à jour. Mettre à jour WordPress, votre thème ou vos extensions ne règle rien : c’est la version de PHP sur laquelle tourne votre site qui doit être mise à jour.

Ce guide explique ce qu’est PHP2Shell, comment vérifier si votre site est concerné, quoi demander à votre hébergeur et que faire si la mise à jour ne peut pas avoir lieu aujourd’hui.

Ce qu’est PHP2Shell

Les travaux de Wiz Research, OpenAI Codex Security et Calif ont mis au jour deux catégories apparentées de bugs de sécurité mémoire dans le moteur PHP :

• CVE-2026-109618, corruption en cas de mémoire épuisée. La façon dont PHP gère l’épuisement de la mémoire peut corrompre son état interne. Un attaquant peut s’en servir pour exécuter du code en tant que worker web PHP, sans se connecter.
• CVE-2026-109619, état global résiduel d’une requête à l’autre. Des données d’une requête peuvent survivre jusqu’à la suivante. Il en résulte un use-after-free qui peut faire fuiter la mémoire du worker ou permettre d’exécuter du code.

Comme la faille se trouve dans PHP, votre propre code n’a pas besoin de contenir le moindre bug. D’après les chercheurs, même une page « Hello World » sur une version de PHP concernée peut être exposée. WordPress, Drupal et Joomla étaient simplement les applications qui leur ont servi à démontrer une exécution de code à distance sans authentification. L’équipe PHP a publié des versions corrigées le jour même.

Pour un site WordPress, deux conséquences comptent avant tout :

1. Prise de contrôle du serveur. Exécuter du code en tant que worker PHP signifie en général que l’attaquant peut modifier des fichiers, ajouter un administrateur, installer une porte dérobée ou atteindre la base de données.
2. Vol de données silencieux. La fuite de mémoire fonctionne sans exécuter de code malveillant et peut donc laisser peu de traces. La mémoire d’un worker PHP très sollicité peut contenir les mots de passe et les cookies d’autres visiteurs, le mot de passe de votre base de données et des clés d’API.

Mon site est-il concerné ?

Presque certainement, sauf si votre PHP a été mis à jour le 21 octobre 2026 ou après. Les chercheurs ont trouvé des versions concernées jusqu’à PHP 5.4. Voici les premières versions corrigées pour chaque branche maintenue :

PHP 8.1, 8.0 et toutes les versions 7.x ne sont plus maintenues par le projet PHP et ne figurent pas dans ce tableau. Si votre site tourne sur l’une d’elles, il n’existe aucune version corrigée à installer : vous devez passer à une branche maintenue.

Pour connaître votre version exacte dans WordPress, ouvrez Outils → Santé du site → Infos et dépliez la section Serveur. La ligne « Version de PHP » affiche le numéro complet, par exemple 8.3.36. Les deux premières parties (8.3) ne suffisent pas : c’est le dernier nombre qui compte.

Comment corriger la faille

La seule correction complète est un environnement PHP corrigé, suivi d’un redémarrage.

1. Mettez à jour PHP dans chaque environnement. Sur votre propre serveur, installez les paquets mis à jour de votre distribution dès leur publication, ou la version officielle disponible sur php.net. En hébergement infogéré ou mutualisé, c’est l’hébergeur qui met PHP à jour : demandez-lui directement si votre offre utilise déjà la version corrigée.
2. Redémarrez PHP. Un nouveau paquet PHP n’a aucun effet tant que les processus en cours ne sont pas remplacés. Redémarrez PHP-FPM, Apache avec mod_php et tous les workers PHP qui tournent en continu.
3. Vérifiez le résultat. Retournez dans Santé du site. La version de PHP doit maintenant être égale ou supérieure à la version corrigée de votre branche.
4. N’oubliez pas les autres environnements. Les sites de préproduction (staging), une deuxième version de PHP sélectionnée dans votre panneau d’hébergement, le PHP utilisé pour les tâches cron et WP-CLI, ainsi que les images de conteneurs comptent aussi.

Si votre panneau d’hébergement propose un sélecteur de version PHP, choisir « 8.3 » ou « 8.4 » n’est sûr que si l’hébergeur a déjà installé la version corrigée derrière cette étiquette. Santé du site vous dit ce qu’il en est vraiment.

Si vous ne pouvez pas mettre à jour aujourd’hui

Les chercheurs proposent des mesures temporaires. Chacune bloque certaines voies d’attaque, aucune ne les bloque toutes, et certaines peuvent perturber votre site : testez d’abord.

• fatal_error_backtraces = 0 si votre version de PHP le permet.
• Abaissez post_max_size et max_input_nesting_level autant que vos formulaires et vos envois de fichiers le permettent, et définissez session.upload_progress.enabled = 0 si rien n’utilise la progression des envois.
• Recyclez plus souvent les workers PHP-FPM avec un pm.max_requests plus bas (au prix de performances moindres).
• memory_limit = -1 supprime la voie de la limite mémoire sur laquelle reposent certaines attaques, mais confie l’épuisement de la mémoire au système d’exploitation. Ne l’utilisez qu’avec une limite au niveau du système d’exploitation, comme memory.max de cgroup v2, et ne la remplacez jamais par RLIMIT_AS ou RLIMIT_DATA, qui, selon l’avis de sécurité de PHP, peuvent déclencher le même bug.

Masquer les erreurs PHP (display_errors, error_reporting ou @) ne fait pas partie de ces mesures : selon le projet PHP, cela n’aide pas.

Les fournisseurs de pare-feu et de CDN ont publié des règles pour PHP2Shell. Elles peuvent réduire l’exposition, mais les chercheurs sont clairs : une règle de protection ne remplace pas la mise à jour de PHP.

Les signes à surveiller

Aucune ligne de journal ne prouve à elle seule une attaque. Les chercheurs citent des signaux qui méritent une enquête : des cookies PHPSESSID anormalement grands ou malformés dans les réponses, des requêtes multipart étranges suivies d’erreurs de limite mémoire ou de rafales de réponses HTTP 500, et des workers PHP qui plantent ou redémarrent sans raison. Leur absence ne prouve pas que votre site est sain, car la fuite de mémoire peut ne rien laisser dans les journaux de WordPress.

Si vous constatez ces signes, traitez la situation comme un incident possible. Notre guide des signes d’un site WordPress piraté vous aide pour les premières vérifications. Comme la mémoire divulguée peut contenir des secrets, changez après la mise à jour le mot de passe de la base de données, les clés et salages de wp-config.php et toutes les clés d’API. Si des données personnelles ont pu être exposées, le compte à rebours du RGPD commence : consultez notre guide de notification d’une violation sous 72 heures.

Par où commencer

1. Ouvrez Outils → Santé du site → Infos → Serveur et notez la version exacte de PHP de chacun de vos sites.
2. Comparez-la avec le tableau ci-dessus. Tout ce qui est inférieur à la version corrigée, ou en PHP 8.1 ou plus ancien, demande une action dès aujourd’hui.
3. Mettez PHP à jour ou demandez la version corrigée à votre hébergeur, puis assurez-vous que PHP-FPM ou Apache a bien été redémarré.
4. Vérifiez de nouveau Santé du site et conservez la capture d’écran comme preuve de la correction.
5. Passez vos journaux en revue à la recherche des signes ci-dessus et renouvelez vos secrets si quelque chose vous paraît anormal.

Sources : php2shell.com, annonce de la PHP Foundation, Wiz Research.