PHP2Shell et migrations PHP : ce que deux incidents m'ont appris sur la sécurité d'un site

Le 21 octobre 2026, deux failles critiques ont été révélées dans PHP, le langage qui fait tourner près de 70 % des sites web, WordPress compris. Leur surnom, PHP2Shell, résume bien le danger : un attaquant peut prendre la main sur un serveur sans jamais se connecter.

Il a fallu réagir vite sur les sites que je gère. Et comme cette année m’a déjà valu deux migrations PHP mouvementées chez Infomaniak, j’en profite pour partager ce que j’en retiens : ce qu’il faut savoir sur PHP2Shell, quelle version choisir, et surtout les erreurs à éviter quand on change de version.

PHP2Shell, de quoi parle-t-on ?

PHP2Shell désigne deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 en gravité. Elles touchent toutes les versions de PHP non corrigées qui servent des pages web.

Une attaque sans identifiant ni mot de passe

Les deux failles viennent de la façon dont PHP gère sa mémoire entre les requêtes. Une simple requête envoyée au serveur suffit à y exécuter du code, avant même que le site ne réagisse. Un code d’exploitation a fuité avant la publication des correctifs, et les premières attaques ont servi à installer des portes dérobées et des mineurs de cryptomonnaie.

Pourquoi mettre à jour WordPress ne suffit pas

La faille est dans PHP lui-même, pas dans WordPress ni dans les extensions. Seule la mise à jour de PHP sur le serveur protège le site. Et si le site a été exposé avant le correctif, il faut aussi vérifier qu’aucun fichier malveillant n’y a été déposé : corriger la faille ne nettoie pas un site déjà compromis.

Quelle version de PHP utiliser en 2026 ?

Un site est protégé s’il tourne sur l’une des versions corrigées ci-dessous, ou plus récente. PHP 8.1 et les versions antérieures n’ont reçu aucun correctif : il faut les abandonner.

Version	Version corrigée minimale	Correctifs de sécurité jusqu’au	Mon conseil
8.5	8.5.12	31 décembre 2029	Le meilleur choix pour un nouveau site
8.4	8.4.27	31 décembre 2028	Un bon choix
8.3	8.3.36	31 décembre 2027	Correct, prévoir la prochaine migration
8.2	8.2.35	31 décembre 2026	Corriger tout de suite, migrer avant la fin de l’année
8.1 et antérieures	Aucune	Terminé	Migrer immédiatement

Comment vérifier sa version

La version exacte s’affiche dans le panneau de contrôle de l’hébergeur, ou dans WordPress sous Outils > Santé du site > Informations > Serveur. Sur un hébergement mutualisé, on ne corrige pas PHP soi-même : il faut demander à l’hébergeur de confirmer que son serveur utilise une version corrigée.

Les conseils classiques des hébergeurs, à nuancer

Face à PHP2Shell, plusieurs hébergeurs ont envoyé à leurs clients les mêmes recommandations d’hygiène générale. Elles restent utiles, mais certaines méritent d’être complétées.

Ce qui reste valable

Mettre à jour WordPress, les thèmes et les extensions.
Supprimer les extensions inutilisées, et pas seulement les désactiver.
Régler les droits des fichiers à 644 et des dossiers à 755, et protéger davantage wp-config.php (600 ou 640).
Désactiver l’affichage des erreurs PHP (display_errors) en production.
Surveiller les fichiers inconnus, en particulier les fichiers .php dans le dossier des médias.

Ce qui est dépassé ou manquant

Le réglage register_globals, encore cité dans certains messages, n’existe plus depuis PHP 5.4. Surtout, ces listes oublient souvent l’essentiel pour PHP2Shell : vérifier que PHP lui-même est à jour. J’y ajoute des sauvegardes régulières stockées hors du serveur et une authentification à deux facteurs pour tous les comptes administrateurs.

Retour d'expérience : deux migrations PHP chez Infomaniak

Sur le papier, changer de version PHP se résume à un clic dans le panneau de l’hébergeur. En pratique, chez Infomaniak, cette migration vers PHP 8.5 a déplacé les sites sur de nouveaux serveurs, avec de nouvelles adresses IP. Ce détail a provoqué deux “pannes” cette année.

Avril 2026 : une adresse IP qui change, une fonctionnalité en panne

En avril, j’ai migré deux sites de PHP 8.3 à PHP 8.5. L’un d’eux utilise une extension développée sur mesure, qui interroge une base de données par des appels JSON. Pour des raisons de sécurité, seule une adresse IP était autorisée à faire ces appels.

Avec les nouveaux serveurs, l’adresse IP a changé et la fonctionnalité a cessé de fonctionner. La cause était facile à identifier : j’ai récupéré la nouvelle adresse et l’ai transmise à la personne qui gère les autorisations. La panne a duré deux heures. Nous avons eu de la chance que cette personne ne soit pas en vacances.

Octobre 2026 : du mode maintenance à la page 404

Quand la menace PHP2Shell est apparue, l’équipe en charge du webshop a dû migrer ses serveurs Infomaniak vers la version de PHP 8.5 le jeudi. Le webshop a été mis en maintenance, puis la maintenance s’est transformée en page 404.

La raison : le webshop n’est pas hébergé sur le même domaine que le site vitrine, mais il est accessible sur un sous-domaine grâce aux DNS. Les DNS pointaient donc toujours vers les anciennes adresses IP. Les administrateurs n’avaient pas testé les sites après la migration et n’avaient pas réalisé que les IP avaient changé.

J’ai identifié le problème dès le vendredi matin et leur ai demandé les nouvelles adresses IP à indiquer dans les DNS. Nous ne pensions pas que le webshop resterait hors ligne aussi longtemps, et nos clients n’ont pas été prévenus.

Les leçons à retenir

Garder toutes les versions à jour

PHP, WordPress, thèmes, extensions : tout doit suivre. Une version à jour se migre plus facilement, et en cas d’alerte comme PHP2Shell, le correctif s’applique sans tout remettre en question.

Remplacer une extension obsolète

Une extension qui n’est plus maintenue finit par bloquer une mise à jour ou par ouvrir une faille. Mieux vaut la remplacer avant qu’elle ne devienne un problème.

Anticiper toutes les implications d'une migration

Une migration ne se limite pas au code. Avant de lancer quoi que ce soit, je liste ce qui dépend du serveur :

adresses IP autorisées par des services externes
enregistrements DNS et sous-domaines
temps d’indisponibilité
personnes à prévenir.

Autant d’éléments à intégrer au cahier des charges dès le départ.

Toujours tester

Juste après la migration, on teste chaque site, chaque sous-domaine et chaque fonctionnalité qui dépend d’un service externe. Un test de quelques minutes aurait évité la page 404 du webshop.

Prévoir la communication client

Si un webshop passe en maintenance, ses clients doivent le savoir. Une simple fenêtre d’information (“pop up” ou “modal”) sur le site vitrine aurait évité bien des incompréhensions.

Pas de déploiement majeur le vendredi

Une panne découverte le vendredi peut durer tout le week-end, faute de personnes disponibles pour la corriger. Les migrations importantes se planifient en début de semaine.

Checklist avant et après une migration PHP

Avant

Vérifier la version exacte de PHP de chaque site
Tester le site sur une copie (staging) avec la nouvelle version
Lister les adresses IP autorisées, les enregistrements DNS et les sous-domaines concernés
Prévenir les personnes qui gèrent les autorisations et les DNS, et vérifier leur disponibilité
Faire une sauvegarde complète hors du serveur
Planifier la migration en début de semaine
Préparer le message d’information pour les clients

Après

Tester chaque site, chaque sous-domaine et chaque fonctionnalité connectée à un service externe
Vérifier si les adresses IP ont changé et mettre à jour DNS et autorisations
Rechercher les fichiers suspects et lancer un scan de sécurité
Changer les mots de passe si le site a pu être exposé

En résumé

PHP2Shell rappelle que la sécurité d’un site dépend aussi de ce qui tourne sous WordPress. Mais mes deux incidents de l’année montrent qu’une migration mal préparée peut faire autant de dégâts qu’une faille. Mettre à jour, anticiper, tester et communiquer : c’est ce qui garantit la cohérence et la performance d’un site sur la durée.