# Pourquoi une mise à jour de WordPress n'aide pas contre PHP2Shell

> Une mise à jour de WordPress n'aide pas contre la faille PHP2Shell : quelle couche compte vraiment et ce que les exploitants WordPress doivent vérifier.

Source : https://phpsos.de/fr/blog/warum-wordpress-update-nicht-hilft/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** une mise à jour de WordPress n'aide pas contre la faille PHP2Shell, car l'erreur ne se trouve pas dans WordPress mais dans PHP, le logiciel du serveur qui exécute WordPress. Selon Dr. Web, WordPress.org ne prévoit donc pas non plus de mise à jour propre. Seule une mise à jour de PHP sur le serveur, avec redémarrage de tous les processus PHP, protège. Elle est en règle générale installée par votre hébergeur ou exploitant de serveur.

## Le point de départ : « Mais nous avons tout mis à jour »

Après les premiers gros titres sur PHP2Shell, de nombreux exploitants ont fait ce qui paraissait évident : ouvrir le tableau de bord WordPress, cliquer sur « Mettre à jour maintenant », extensions et thèmes avec. Ensuite, tout est au vert, et le sentiment dit : c'est réglé.

Avec cette faille, le sentiment trompe. Cela ne tient pas à WordPress, mais à l'endroit où se trouve l'erreur. Cloudflare souligne lui aussi dans son avis qu'une mise à jour du code applicatif ou des extensions ne corrige pas les failles.

## Mise à jour de WordPress et faille PHP : le modèle en couches

Un site WordPress se compose de plusieurs couches qui reposent les unes sur les autres. Chaque couche a ses propres mises à jour et souvent ses propres responsables :

| Couche | Exemple | Qui met à jour typiquement | Concernée par PHP2Shell ? |
|---|---|---|---|
| Système d'exploitation | Debian, Ubuntu, AlmaLinux | hébergeur ou administrateur du serveur | non, mais fournit souvent le paquet PHP |
| Serveur web | Apache, Nginx, LiteSpeed | hébergeur ou administrateur du serveur | le mode d'exécution influence le risque |
| Environnement d'exécution PHP | PHP-FPM, mod_php | hébergeur ou administrateur du serveur | oui, c'est ici que se trouve la faille |
| Noyau WordPress | WordPress | exploitant ou agence | non |
| Extensions et thèmes | WooCommerce, page builder | exploitant ou agence | non |

Le bouton de mise à jour du tableau de bord n'atteint que les deux lignes du bas. L'environnement d'exécution PHP se situe en dessous et est invisible pour WordPress. La manière dont d'autres systèmes reposent sur PHP est décrite dans l'article [CMS et boutiques sur PHP](https://phpsos.de/fr/php/cms-und-shops-auf-php/).

## Pourquoi WordPress ne peut pas fermer la faille

On pourrait penser que WordPress peut « programmer autour ». Avec PHP2Shell, cela ne fonctionne pas, pour deux raisons.

Premièrement, les deux erreurs tiennent à la manière dont PHP traite les requêtes puis nettoie. Cela se produit indépendamment du programme qui s'exécute dans PHP. Deuxièmement, l'équipe PHP a démontré pour Apache avec mod_php un exploit qui agit avant même que le code de l'application ne s'exécute. WordPress, ses extensions et toute extension de sécurité n'ont alors pas même l'occasion d'intervenir.

Pour la même raison, aucune « extension de durcissement » qui modifie des paramètres via `ini_set()` n'aide. php.net déconseille expressément d'appliquer des mesures transitoires par cette voie.

### Et avec un WordPress géré ?

Dans les offres de WordPress géré, le fournisseur s'occupe souvent non seulement des mises à jour de WordPress, mais aussi du serveur sous-jacent. C'est un avantage pour PHP2Shell, mais pas un automatisme. Demandez concrètement si la mise à jour de PHP a été installée et si tous les processus PHP ont été redémarrés. L'affirmation « Nous tenons votre WordPress à jour » ne répond pas à cette question.

### Plusieurs sites, une seule installation PHP

Les agences et entreprises avec plusieurs sites devraient connaître une particularité : sur un serveur, de nombreuses installations WordPress partagent souvent la même version de PHP. Si celle-ci n'est pas corrigée, toutes sont concernées, quelle que soit la qualité d'entretien de chaque site. À l'inverse, une mise à jour de PHP protège toutes les installations à la fois, à condition que tous les processus PHP correspondants soient redémarrés ensuite. Qui exploite plusieurs versions de PHP en parallèle doit mettre à jour chacune individuellement.

> **Important:**
> Un tableau de bord WordPress au vert ne dit rien sur PHP2Shell. Ce qui est décisif, c'est le niveau de correctif de PHP sur le serveur et le redémarrage de tous les processus PHP.

## Bien lire la version de PHP dans WordPress

WordPress affiche la version de PHP : dans le tableau de bord, sous Outils, Santé du site, dans la zone Infos, à la section Serveur. C'est un bon premier indice, mais pas une preuve.

Si une branche comme 8.1 ou plus ancienne y figure, c'est un signal d'alerte clair, car il n'existe plus de mises à jour officielles pour elle. Si 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 y figure, la version corrigée est installée. Si un ancien numéro d'une branche prise en charge y figure, un rétroportage peut malgré tout avoir été appliqué. Les distributions et hébergeurs ne modifient souvent pas le numéro dans ce cas. Seule la confirmation de l'hébergeur ou un regard sur le journal des modifications (changelog) du paquet apporte la clarté. La manière de procéder figure sous [Vérifier la version de PHP et le niveau de correctif](https://phpsos.de/fr/php2shell/php-version-pruefen/).

## Ce que les exploitants WordPress devraient faire à la place

1. **Interroger l'hébergeur ou l'exploitant du serveur :** PHP est-il corrigé, quand, et tous les processus PHP ont-ils été redémarrés ? Réponse par écrit.
2. **Vérifier la branche PHP :** si le site tourne sous 8.1 ou plus ancien, planifier le passage à une branche prise en charge. La version prise en charge par votre version de WordPress figure dans la configuration requise sur wordpress.org. Le changement dans l'espace client est décrit dans [Modifier la version de PHP dans l'espace client de l'hébergeur](https://phpsos.de/fr/blog/php-version-hosting-aendern/).
3. **Rechercher des traces :** nouveaux fichiers PHP dans `wp-content/uploads`, comptes administrateur inconnus, entrées étrangères dans `mu-plugins`. Les cachettes typiques sont décrites sur la page [WordPress et PHP2Shell](https://phpsos.de/fr/plattformen/wordpress/).
4. **Tenir malgré tout WordPress à jour :** le noyau, les extensions et les thèmes corrigent d'autres failles. Cela reste une obligation, mais une autre.
5. **Clarifier la responsabilité :** si une agence s'occupe du site, consigner si elle est aussi responsable de PHP ou seulement de WordPress.

Ce dernier point crée souvent des lacunes. L'agence entretient WordPress, l'hébergeur le serveur, et chacun croit que l'autre a PHP2Shell à l'œil.

## Comment PHP SOS aide-t-il concrètement ?

- **Clarifier les couches :** nous déterminons qui, pour votre site WordPress, est responsable de quelle couche.
- **Mettre PHP à jour :** sur des serveurs propres ou gérés, nous installons la mise à jour de PHP et redémarrons tous les processus.
- **Vérifier WordPress :** nous recherchons des traces d'une attaque dans les fichiers, la base de données et les comptes.
- **Preuve :** vous recevez le niveau de correctif par écrit, aussi pour transmission à l'agence ou aux clients.

Le déroulement est décrit dans le [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/).

## Conclusion

La mise à jour de WordPress est un bon entretien, mais contre PHP2Shell c'est la mauvaise couche. La faille se situe un étage plus bas, dans PHP sur le serveur. Qui le comprend pose la bonne question au bon endroit : PHP est-il corrigé, redémarré et prouvé ?


## Questions fréquentes

**WordPress publie-t-il une mise à jour de sécurité contre PHP2Shell ?**  
Selon Dr. Web, WordPress.org ne prévoit pas de mise à jour contre PHP2Shell, car la faille se trouve dans l'interpréteur PHP sur le serveur. Seule une mise à jour de PHP par l'hébergeur ou l'exploitant du serveur y remédie.

**Où vois-je la version de PHP dans WordPress ?**  
Dans le tableau de bord, sous Outils, Santé du site, dans la zone Infos, à la section Serveur. Le numéro affiché ne dit toutefois pas avec certitude si le correctif est installé, car les hébergeurs intègrent souvent les corrections sous forme de rétroportage sans nouveau numéro de version.

**Une extension de sécurité protège-t-elle contre PHP2Shell ?**  
Très peu. Une extension s'exécute elle-même dans PHP et ne devient active que lorsque WordPress est chargé. Avec Apache et mod_php, selon l'équipe PHP, un exploit a été démontré avant même que le code de l'application ne s'exécute. Une extension ne peut pas intervenir à ce niveau.

**Dois-je quand même mettre WordPress à jour ?**  
Oui. Les versions actuelles de WordPress, des thèmes et des extensions corrigent d'autres failles et font partie d'un bon entretien. Elles ne résolvent simplement pas le problème PHP2Shell.

## Sources

- [Dr. Web: PHP2Shell, Update der PHP-Versionen](https://www.drweb.de/php2shell-update-php-versionen/)
- [php.net : avis de sécurité](https://www.php.net/)
- [WordPress.org](https://wordpress.org/)
- [Blog Cloudflare : Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)