Non. PHP2Shell est une faille de PHP, le moteur qui exécute WordPress, et non de WordPress lui-même : seule une version de PHP corrigée sur le serveur la ferme (8.2.35, 8.3.36, 8.4.27 ou 8.5.12, publiées le 21 octobre 2026). Vous pouvez vérifier la vôtre en une minute dans Outils › Santé du site.
Depuis 2018, j’accompagne avec mon équipe de Gamache Média, agence web de Saint-Lambert, des PME du Grand Montréal dans leur présence en ligne. Nous concevons leurs sites web, et nous en hébergeons pour plusieurs d’entre elles. Des alertes de sécurité, on en voit passer souvent. La plupart touchent une extension précise et se règlent par une mise à jour dans WordPress.
La faille PHP2Shell, corrigée le 21 octobre 2026, est différente. Vous avez peut-être vu passer le titre de La Presse : une faille critique menacerait 70 % des sites web. Le chiffre vient de la place qu’occupe PHP, le langage qui fait tourner la grande majorité des sites dont on connaît la technologie, WordPress en tête.
Imaginez : vous lisez ce titre en prenant votre café. Vous ouvrez votre WordPress, tout est à jour, l’extension de sécurité affiche son crochet vert. Vous vous rassurez. À tort : cette fois, ni WordPress ni l’extension n’y peuvent rien.
Qu’est-ce que PHP2Shell?
PHP2Shell est le nom donné à deux failles critiques de PHP, CVE-2026-109618 et CVE-2026-109619, corrigées en urgence par le projet PHP le 21 octobre 2026. Elles permettent d’exécuter du code sur un serveur web sans compte ni mot de passe. Trois faits expliquent pourquoi tout le monde en parle.
Une seule requête suffit. Un attaquant peut exécuter son propre code sur le serveur, ce qui ouvre la porte à tout le reste : porte dérobée, copie de la base de données, pourriel envoyé au nom de votre domaine. Le projet PHP attribue à chacune des deux failles une note de gravité de 9,2 sur 10.
La faille a fuité avant le correctif. Son existence était connue avant la date de publication prévue, des preuves de concept circulent publiquement et Cloudflare a déjà rapporté des tentatives d’exploitation. Le centre national de cybersécurité du Royaume-Uni (NCSC) recommande de mettre hors ligne ce qu’on ne peut pas corriger rapidement.
Toutes les installations sont concernées. Apache avec mod_php (le cas le plus exposé), PHP-FPM, php-cgi, FrankenPHP, LiteSpeed : toutes les façons de servir un site en PHP sont touchées. Et les versions 8.1 et plus anciennes ne recevront plus de version officielle.
Pourquoi un WordPress à jour ne protège-t-il pas contre PHP2Shell?
Parce que PHP2Shell ne se trouve pas dans WordPress. Une faille de WordPress ou d’une extension se trouve dans le code de votre site, alors que PHP2Shell se trouve un étage plus bas, dans le moteur qui exécute ce code. L’attaque se produit au moment où PHP lit la requête, avant même que WordPress ne démarre.
| À comparer | Faille de WordPress ou d’une extension | PHP2Shell |
|---|---|---|
| Où elle se trouve | Dans le code du site | Dans PHP, le moteur qui exécute ce code |
| Qui la corrige | Vous ou votre agence, depuis WordPress | L’administrateur du serveur : votre hébergeur, ou l’agence qui héberge votre site |
| Extension de sécurité | Wordfence, par exemple, peut bloquer l’attaque | Arrive trop tard : l’attaque a lieu avant WordPress |
| Où vérifier | Tableau de bord › Mises à jour | Outils › Santé du site › Infos › Serveur |
Précision importante : un pare-feu placé devant le site peut bloquer les variantes d’attaque déjà connues, et Cloudflare a déployé des règles pour tous ses clients, y compris ceux du forfait gratuit. C’est une mesure d’attente. Le projet PHP est clair : seule la mise à jour de PHP corrige la faille.
Un cas concret : notre 21 octobre
Pour les sites que nous hébergeons, l’équipe de Gamache Média a fait le tour complet le jour même de la sortie du correctif. Dans l’ordre :
- Recenser tout ce qui tourne, y compris les sous-domaines et les copies de préproduction. Ces versions de travail, qu’on oublie une fois le nouveau site lancé, sont aussi vulnérables que le site principal.
- Ne changer qu’une seule chose. Le panneau proposait plusieurs mises à jour à la fois, et un bouton « Tout mettre à jour ». En urgence, c’est le piège : si un site tombe après cinq changements, impossible de savoir lequel accuser. Nous avons appliqué uniquement celle de PHP.
- Vérifier chaque site, avant et après, en contournant le cache. Résultat : tous les sites répondaient exactement comme avant.
C’est la vérification suivante qui a tout changé. Le tableau du panneau affichait « 8.3 » partout. Nous ne l’avons pas cru sur parole et avons ouvert la page Santé du site d’un WordPress. Elle indiquait une autre version de PHP, que la mise à jour n’avait pas touchée. Beaucoup de serveurs d’hébergement, notamment ceux qui fonctionnent sous CloudLinux, font cohabiter plusieurs PHP : celui du serveur, et ceux qui servent réellement les sites.
S’arrêter au tableau, c’était conclure que tout était corrigé alors que les sites ne l’étaient pas. Nous avons donc corrigé aussi la version qui sert les sites : à midi, le 21 octobre, Santé du site affichait une version de PHP corrigée. Puis nous avons cherché des traces d’intrusion, dans les incidents de l’outil de sécurité du serveur, dans les fichiers PHP déposés depuis le 20 octobre et par un nouveau balayage antivirus complet. Résultat : aucune infection.
Comment vérifier votre version de PHP en une minute?
Dans WordPress, la page Santé du site donne le numéro exact de PHP utilisé par votre site. Connectez-vous, puis :
- ouvrez Outils › Santé du site, onglet Infos ;
- dépliez la section Serveur ;
- lisez la ligne Version de PHP.
Comparez ensuite avec ces repères :
- 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus : votre site est corrigé.
- Un numéro plus petit en 8.2, 8.3, 8.4 ou 8.5 : écrivez à votre hébergeur aujourd’hui.
- 8.1, 8.0 ou 7.4 : corrigé seulement si votre hébergeur a appliqué lui-même le correctif, et le numéro ne change pas. Demandez une confirmation écrite.
- 7.3 ou moins : aucun correctif n’existe. Il faut passer à une version récente sans attendre.
C’est la version que le site déclare lui-même qui compte, pas celle qu’affiche un panneau de contrôle. Pas d’accès à WordPress? Demandez le numéro complet à la personne qui gère votre site.
Votre version n’est pas corrigée, ou vous ne trouvez pas la page Santé du site? Écrivez à notre équipe : nous vous disons où vous en êtes et quoi faire.
Quelles questions poser à votre hébergeur?
Si votre site n’est pas hébergé chez nous, quatre questions suffisent pour savoir si votre hébergeur a traité PHP2Shell.
1. Quelle version de PHP sert réellement mon site?
Demandez le numéro complet (8.3.36, pas seulement « 8.3 »), et la version qui sert le site, pas celle du serveur. Comme on l’a vu plus haut, les deux peuvent différer.
2. Les correctifs rétroportés sont-ils appliqués?
Si votre site tourne en 7.4, 8.0 ou 8.1, le projet PHP a publié des correctifs minimaux que chaque hébergeur doit appliquer lui-même. Le numéro de version ne change pas : seule une confirmation écrite vous l’apprendra.
3. Un pare-feu bloque-t-il les attaques connues en attendant?
Insistez sur « bloque ». Un pare-feu peut être réglé pour seulement signaler les attaques, sans les arrêter.
4. Avez-vous cherché des fichiers déposés depuis le 20 octobre?
Une faille corrigée ne dit rien de ce qui a pu entrer avant. Une analyse des fichiers récents, surtout dans le dossier des images, est la façon la plus simple de le savoir.
Votre hébergeur tarde à répondre ou reste vague? C’est souvent le signe qu’il est temps de changer. Parlons de l’hébergement de votre site.
Comment savoir si votre site a été piraté?
Quatre signes doivent vous alerter dans les semaines qui suivent PHP2Shell :
- Des fichiers .php dans wp-content/uploads. Ce dossier sert aux images et aux documents : un fichier PHP n’a rien à y faire.
- Des comptes administrateurs que vous n’avez pas créés, dans la section Utilisateurs.
- Des redirections vers des sites inconnus, parfois seulement sur mobile ou depuis Google, pour passer inaperçues.
- Un avertissement de sécurité dans la Search Console de Google.
Au moindre doute, demandez à votre hébergeur une analyse complète, et changez les mots de passe d’administration une fois le correctif appliqué.
Un de ces signes sur votre site? Contactez-nous aujourd’hui : nous regardons avec vous par où commencer, sans engagement.
Par où commencer
Faites le test d’une minute aujourd’hui. Si votre version est corrigée, tant mieux : gardez quand même les quatre questions sous la main pour la prochaine alerte. Sinon, écrivez à votre hébergeur avant la fin de la journée.
Si votre site est hébergé chez nous, vous n’avez rien à faire. Si nos vérifications révèlent quoi que ce soit qui le concerne, nous vous écrirons directement. Et si votre compte contient une ancienne copie de préproduction que vous n’utilisez plus, dites-le-nous : nous la fermerons.
Chez Gamache Média, à Saint-Lambert, l’hébergement se traite comme le reste de notre travail. Quelqu’un lit les avis techniques le matin même, change une seule chose à la fois, vérifie chaque site avant et après, et lit la version réelle plutôt que de croire le tableau de bord.
Questions fréquentes sur PHP2Shell
Wordfence protège-t-il contre PHP2Shell?
Non. Wordfence et les autres extensions de sécurité fonctionnent à l’intérieur de WordPress, alors que PHP2Shell est exploité au moment où PHP lit la requête, avant que WordPress ne démarre. Seule une mise à jour de PHP sur le serveur (8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récente) corrige la faille. Ces extensions restent utiles contre les failles de WordPress et de ses extensions.
Quelles versions de PHP corrigent PHP2Shell?
Les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12, publiées par le projet PHP le 21 octobre 2026, ainsi que toutes les versions plus récentes de ces branches. Pour PHP 7.4, 8.0 et 8.1, le projet a seulement publié des correctifs minimaux que l’hébergeur doit appliquer lui-même, sans changer le numéro de version. PHP 7.3 et les versions antérieures n’ont aucun correctif.
PHP2Shell touche-t-il seulement les sites WordPress?
Non. PHP2Shell touche PHP lui-même, donc tout site servi par PHP : WordPress, WooCommerce, Drupal, Joomla, Magento ou une application sur mesure. Toutes les façons de faire tourner PHP sont concernées, d’Apache avec mod_php à PHP-FPM et LiteSpeed. Si votre site est écrit en PHP, sa version doit être 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récente.
Qui doit corriger PHP2Shell sur mon site?
L’administrateur du serveur : votre hébergeur, ou l’agence qui héberge votre site. Sur un hébergement partagé, vous ne pouvez pas mettre PHP à jour vous-même, mais votre panneau de contrôle vous laisse souvent choisir une version plus récente. Après tout changement, vérifiez le numéro dans Outils › Santé du site : c’est la version que le site utilise réellement qui compte.
Mon site tourne en PHP 7.4 : est-il en danger?
Oui, sauf si votre hébergeur confirme par écrit avoir appliqué le correctif minimal publié par le projet PHP. PHP 7.4 ne reçoit plus de version officielle depuis novembre 2022, et son numéro ne change pas après ce correctif. Le passage à PHP 8.2 ou plus demande de tester le site et ses extensions les plus anciennes : c’est le bon moment pour le planifier.
Sources
- PHP, annonces des versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (21 octobre 2026)
- PHP, avis de sécurité GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- Help Net Security, PHP2Shell: Critical PHP vulnerabilities patched, update now! (21 octobre 2026)
- Tenable, php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions
- Huntress, Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
