Publié le 2 novembre 2026

Faille PHP2Shell : que faire pour votre site WordPress

Vous avez peut-être reçu un courriel de votre hébergeur, de votre prestataire ou d'un organisme professionnel : deux vulnérabilités critiques de PHP, CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell » et notées 9,2 sur 10, permettent d'exécuter du code à distance sur un serveur, sans mot de passe. Si vous avez un site WordPress, vous êtes concerné : WordPress est écrit en PHP et tourne sur le PHP de votre hébergeur.

Le point essentiel tient en une phrase : ce n'est pas une faille de WordPress. Le défaut est dans le moteur PHP et se déclenche dès la réception de la requête, avant que WordPress ou la moindre extension ne s'exécute. Mettre WordPress à jour ou installer une extension de sécurité ne la corrige pas ; la correction se fait sur le serveur. Ce guide indique qui doit agir selon votre hébergement, comment vérifier, comment mettre à jour un serveur, quoi faire si c'est impossible tout de suite, et comment contrôler ensuite que rien ne s'est passé.

Ce que permettent CVE-2026-109618 et CVE-2026-109619

Les deux failles touchent la façon dont PHP gère la mémoire pendant le traitement d'une requête :

• CVE-2026-109618 — quand PHP manque de mémoire en pleine lecture d'une requête (l'envoi d'un fichier par formulaire, par exemple), il peut laisser des données à moitié construites, que le nettoyage de fin de requête traite ensuite comme valides.
• CVE-2026-109619 — un état interne propre à une requête peut survivre à la libération de sa mémoire ; la requête suivante traitée par le même processus PHP le réutilise alors.

Dans les deux cas, le résultat est une exécution de code à distance sans authentification : un inconnu fait exécuter ses propres commandes par votre serveur, avec les droits du site. Sur un WordPress, cela veut dire lire wp-config.php et le mot de passe de la base de données, créer un compte administrateur, déposer une porte dérobée ou envoyer du spam depuis votre hébergement.

Selon le projet PHP, toutes les installations qui servent des pages web sont exposées, quel que soit le mode d'exécution : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est jugé le plus élevé avec mod_php, pour lequel une attaque a été démontrée par une simple requête anonyme, avant l'exécution du moindre code de l'application. Le CERT-FR précise que les preuves de concept connues visent des configurations particulières, ce qui n'autorise pas à attendre : les tentatives d'exploitation sont réelles.

Un troisième identifiant, CVE-2026-115560, a été ajouté le 23 octobre. Il suppose une combinaison rare de configuration et de code applicatif, et sera corrigé lors de la prochaine version régulière de PHP ; le réglage qui le neutralise est le même que pour CVE-2026-109619 (voir plus bas). Enfin, ce qui vaut pour WordPress vaut pour tout ce qui tourne sur PHP : Drupal, Magento, PrestaShop, Nextcloud, Dolibarr.

Les versions corrigées, branche par branche

Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Une version égale ou supérieure dans votre branche est corrigée. Les branches 8.1, 8.0 et 7.4, en fin de vie, n'ont pas de version officielle : seulement un correctif minimal publié en code source, que les distributions et les hébergeurs peuvent intégrer. En dessous, rien du projet PHP.

Relevé le 2 novembre 2026 sur php.net. Les rebuilds Windows du 26 octobre (suffixe « -1 », par exemple 8.4.27-1) corrigent une autre faille, dans la bibliothèque Brotli ; le numéro de PHP, lui, ne change pas.

Le piège des numéros sur Debian et Ubuntu

Les distributions Linux appliquent souvent le correctif à leur propre version de PHP sans en changer le numéro. Sur Ubuntu 24.04, un serveur corrigé affiche toujours PHP 8.3.6 : ce qui fait foi, c'est la version du paquet, 8.3.6-0ubuntu0.24.04.13 ou plus. Le numéro que montre WordPress ne suffit donc pas à conclure, dans un sens comme dans l'autre.

Relevé le 2 novembre 2026 sur les trackers de sécurité Debian et Ubuntu. Debian 12 est passée en support à long terme (LTS), d'où un bulletin DLA plutôt que DSA.

Qui doit agir : cela dépend de l'hébergement

• Hébergement mutualisé (OVHcloud, o2switch, Ionos, Infomaniak, Hostinger…) — l'hébergeur gère PHP ; vous ne choisissez que la branche. OVHcloud indique avoir terminé le déploiement le 23 octobre 2026 sur ses quelque 5 000 serveurs, avec ses propres correctifs pour PHP 5.3 à 7.3 et un filtrage sur son pare-feu applicatif, sans action des clients. Ailleurs, consultez la page d'état de l'hébergeur ou demandez-lui par écrit (voir ci-dessous). Les réglages d'attente décrits plus bas ne sont pas à votre portée : un fichier .user.ini ou un ini_set() ne suffit pas, précise le projet PHP.
• Site géré par une agence ou un prestataire — c'est à lui de vérifier et de corriger. Demandez-lui de confirmer par écrit, et gardez la réponse.
• VPS, serveur dédié, instance cloud — l'hébergeur fournit la machine, pas son système : la mise à jour de PHP vous revient, ou revient à la personne qui administre le serveur. C'est l'objet de la section « Mettre à jour PHP sur un serveur ».
• Site en conteneur Docker — l'image contient son propre PHP. Une image construite avant le 21 octobre reste vulnérable même si la machine hôte est à jour : il faut la reconstruire et redéployer.
• Appareils qui embarquent PHP — interfaces d'administration de pare-feu, de standards téléphoniques, de boîtiers réseau. Le correctif passe par une mise à jour du constructeur. L'inventaire du NCSC-NL, le centre de cybersécurité néerlandais, suivait 929 produits au 30 octobre 2026 : 165 corrigés, 217 vulnérables, 345 encore à l'étude.

Ce qu'il faut demander à un hébergeur ou à un prestataire, en une phrase : « Pouvez-vous me confirmer par écrit que le PHP de mon site est corrigé contre CVE-2026-109618 et CVE-2026-109619, par quelle version ou quel rétroportage, et que les processus PHP ont été redémarrés depuis ? » Le redémarrage compte : tant qu'un processus PHP lancé avant la mise à jour tourne, il exécute l'ancien code.

Vérifier la version de PHP depuis WordPress

Dans le tableau de bord : Outils > Santé du site > Informations, puis la section « Serveur », ligne « Version de PHP ». C'est la version qui exécute réellement le site, alors qu'un php -v lancé en SSH peut interroger un autre PHP, celui de la ligne de commande. Trois cas :

• 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus dans la même branche — corrigé.
• Un numéro plus bas sur une branche 8.2 à 8.5 — soit pas corrigé, soit corrigé par rétroportage sans changement de numéro. Sur un serveur à vous, la version du paquet tranche (tableau ci-dessus) ; sur un mutualisé, seule la réponse de l'hébergeur.
• PHP 8.1 ou plus ancien — branche sans version officielle. Même si l'hébergeur a rétroporté le correctif, la prochaine faille ne le sera peut-être pas : planifiez le changement de branche (voir plus bas).

Mettre à jour PHP sur un serveur

Sur un VPS ou un serveur dédié sous Debian ou Ubuntu avec les paquets de la distribution, la correction est une mise à jour ordinaire, suivie d'un redémarrage de PHP. Remplacez 8.3 par votre branche.

# Les paquets PHP installés et leur version
dpkg -l | grep -E '^ii +(php|libapache2-mod-php)'

# Les mises à jour disponibles, puis leur installation
sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt upgrade

# Le correctif est-il présent ? Le journal du paquet cite les deux CVE
apt changelog php8.3-fpm | grep -m2 -E 'CVE-2026-10961[89]'

# Redémarrer PHP : sans cela, les processus déjà lancés gardent l'ancien code
sudo systemctl restart php8.3-fpm     # site servi par PHP-FPM
sudo systemctl restart apache2        # site servi par Apache avec mod_php

Si apt changelog ne cite pas les CVE, vérifiez d'où viennent vos paquets : apt-cache policy php8.3-fpm. Beaucoup de serveurs WordPress utilisent un dépôt tiers (sury.org, PPA ondrej/php) pour disposer d'une version de PHP plus récente que celle de la distribution : c'est alors ce dépôt qui doit publier le correctif. Même logique sous AlmaLinux, Rocky ou Red Hat, où le CERT-EU signalait le 21 octobre que le dépôt Remi n'avait pas encore de paquets corrigés.

sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -m2 -E 'CVE-2026-10961[89]'
sudo systemctl restart php-fpm httpd

# Récupère l'image de base à jour, reconstruit et relance
docker compose build --pull
docker compose up -d

# Vérifier dans le conteneur : 8.3.36 ou plus pour la branche 8.3
docker compose exec <service-php> php -v

Une fois la mise à jour faite, rouvrez la Santé du site : la version affichée doit correspondre au tableau, et systemctl status php8.3-fpm doit montrer un démarrage postérieur à la mise à jour.

Impossible de corriger tout de suite : réduire l'exposition

La mesure qui compte est celle du CERT-EU et du CERT-FR : isoler le serveur d'Internet jusqu'à ce que le correctif soit appliqué et vérifié. Pour un WordPress, cela se fait devant PHP : une page statique servie par Apache ou nginx, une règle de pare-feu, une coupure au niveau du CDN. Une extension de mode maintenance ne sert à rien ici : c'est du code PHP, exécuté après que PHP a lu la requête — trop tard. Restreindre l'accès à /wp-admin ne suffit pas non plus : n'importe quelle adresse servie par PHP peut déclencher la faille.

Par précaution, si le serveur héberge autre chose ou communique avec votre réseau interne, limitez aussi ces accès : un serveur compromis sert souvent de tremplin. Un pare-feu applicatif placé devant le serveur, chez l'hébergeur ou dans un CDN, peut filtrer une partie des attaques, à condition que le serveur ne soit pas joignable directement par son adresse IP. Une extension de sécurité WordPress, elle, arrive après PHP : elle ne bloque rien.

Sur un serveur que vous administrez, le projet PHP donne aussi des réglages d'attente, à poser dans la configuration du serveur (php.ini, pool PHP-FPM, configuration Apache), jamais par .user.ini ni ini_set(). Il le dit sans détour : ils réduisent certains chemins d'attaque, ils ne rendent pas l'installation sûre.

; CVE-2026-109619 et CVE-2026-115560 : suivi de progression des envois désactivé
; (le cœur de WordPress ne s'en sert pas)
php_admin_value[session.upload_progress.enabled] = 0

; CVE-2026-109618 : plus de limite mémoire PHP à atteindre.
; php_admin_value empêche WordPress et ses extensions de la redéfinir.
php_admin_value[memory_limit] = -1

; Requêtes plus petites : 32M quand la médiathèque reçoit des fichiers, 8M sinon
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M

; PHP 8.5 uniquement
; php_admin_value[fatal_error_backtraces] = 0

Puis sudo systemctl restart php8.3-fpm : un réglage n'agit qu'après redémarrage de tous les processus. Deux contreparties à connaître. Sans limite mémoire, un script emballé peut occuper toute la mémoire de la machine : le projet PHP conseille une limite au niveau du conteneur ou du système (cgroup) qui n'arrête que le processus fautif, et déconseille RLIMIT_AS et RLIMIT_DATA, qui provoquent justement l'échec d'allocation vulnérable. Et avec post_max_size à 32M, une vidéo plus lourde ne passera plus par la médiathèque le temps de la correction.

PHP 8.1 ou plus ancien : changer de branche

Un site resté sur PHP 7.4, 8.0 ou 8.1 n'a de correctif que si quelqu'un l'a fabriqué pour lui : le correctif minimal du projet PHP, intégré par une distribution ou un hébergeur, ou un rétroportage maison. Cette fois, c'est arrivé. La sortie durable est de passer à PHP 8.3 ou 8.4, et de ne pas viser 8.2, qui perd ses correctifs le 31 décembre 2026.

Côté WordPress, la version actuelle, 7.1, accepte PHP 7.4 à 8.5. Un WordPress plus ancien se met d'abord à jour, PHP ensuite, une branche à la fois : la méthode et la matrice complète sont dans le guide compatibilité PHP / WordPress. Profitez-en pour appliquer WordPress 7.1.4, publié le 28 octobre 2026 : sans rapport avec PHP2Shell, il corrige les failles de WordPress lui-même, avec des versions équivalentes pour les anciennes branches (7.0.8, 6.9.11… jusqu'à 4.7.39).

Après la correction : vérifier que rien ne s'est passé

Si le site a tourné sur un PHP vulnérable après le 21 octobre, un contrôle s'impose : la mise à jour ferme la porte, elle ne chasse pas un intrus déjà entré. Avec WP-CLI, l'outil en ligne de commande de WordPress, depuis le dossier du site :

# Fichiers du cœur ou des extensions modifiés par rapport à l'original
wp core verify-checksums
wp plugin verify-checksums --all

# Un administrateur que vous ne connaissez pas ?
wp user list --role=administrator

# Des tâches planifiées inconnues ?
wp cron event list

# Aucun fichier PHP n'a sa place dans les médias
find wp-content/uploads -name '*.php'

# Fichiers PHP modifiés depuis le 21 octobre 2026
find . -name '*.php' -newermt '2026-10-21' -not -path './wp-content/cache/*'

La dernière commande remonte aussi les mises à jour légitimes, WordPress 7.1.4 en tête : croisez-la avec verify-checksums avant de conclure. Sans accès en ligne de commande, le menu Utilisateurs, filtré sur « Administrateur », et un passage en FTP dans wp-content/uploads couvrent déjà l'essentiel.

En cas de trace suspecte, supprimer le fichier ne suffit pas : l'intrus a eu les droits du site. Restaurez une sauvegarde antérieure à l'intrusion, ou au 21 octobre 2026 faute de pouvoir la dater (voir la règle 3-2-1), puis changez le mot de passe de la base de données, les clés de sécurité de wp-config.php et les mots de passe des administrateurs, et prévenez l'hébergeur.

Garder une trace de ce qui a été fait

Notez la date, la version de PHP avant et après, qui est intervenu, les mesures d'attente éventuelles et la réponse écrite de l'hébergeur ou du prestataire. Cinq lignes suffisent. C'est ce que demanderont un assureur, un donneur d'ordre ou un client qui vous interroge sur votre sécurité, et c'est le réflexe attendu des entreprises visées par la directive NIS2.

Voir aussi : compatibilité PHP / WordPress · la règle 3-2-1 · instantanés et sauvegardes immuables · directive NIS2 : votre entreprise est-elle concernée ? · contrat d'infogérance TPE