PHP2Shell : la faille PHP qui concerne votre site, et que faire

Le 21 octobre 2026, le projet PHP a publié en urgence des correctifs pour deux failles critiques, surnommées PHP2Shell. PHP fait tourner une très grande partie du web, dont WordPress, PrestaShop, Dolibarr et Laravel : si votre site repose sur l’un d’eux, il est concerné.

Mettre à jour votre CMS ne suffit pas. La faille se trouve dans PHP lui-même, c’est-à-dire sur le serveur, et sa correction dépend de vous ou de votre hébergeur.

Pourquoi cette alerte est différente

Les failles CVE-2026-109618 et CVE-2026-109619 permettent à un attaquant d’exécuter du code sur le serveur, sans compte et à distance. Le projet PHP leur attribue une note de 9,2 sur 10 (CVSS v4.0), et précise que toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Le risque est jugé le plus élevé avec mod_php : une requête peut déclencher l’attaque avant même que le code de votre site ne s’exécute. Autrement dit, un site bien entretenu n’est pas protégé pour autant.

Trois éléments ont fait monter la pression :

• Une fuite avant l’heure : des informations ont circulé en ligne le 20 octobre, et le projet PHP a avancé la publication des correctifs.
• Des attaques déjà constatées : le CERT-FR signale des tentatives d’exploitation, et l’agence américaine CISA a ajouté les deux failles à sa liste des vulnérabilités exploitées.
• Des consignes inhabituelles : le CERT-FR recommande d’isoler les équipements touchés, et la CISA de mettre hors ligne les systèmes qui ne peuvent pas être corrigés.

Quelle version de PHP devez-vous avoir ?

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. En dessous, sur ces mêmes branches, votre site est exposé.

Pour PHP 8.1 et les versions plus anciennes, le projet ne publie plus de mise à jour. Il a seulement fourni des correctifs à compiler soi-même pour les versions 7.4, 8.0 et 8.1.

Attention au numéro de version sur ces anciennes branches. Un hébergeur peut intégrer le correctif sans changer le numéro : 7.4.33 peut donc être vulnérable sur un serveur et corrigé sur un autre. Le numéro seul ne prouve rien. Demandez une confirmation écrite à votre hébergeur.

Comment vérifier votre site

Sur un hébergement mutualisé ou infogéré, écrivez à votre hébergeur : « Le correctif pour CVE-2026-109618 et CVE-2026-109619 est-il appliqué sur la version PHP de mon site ? ». Vérifiez aussi la version choisie dans votre espace d’administration, car un site peut rester sur une ancienne version alors que le serveur en propose une récente.

Sur votre propre serveur, contrôlez chaque version installée, pas seulement celle de la ligne de commande :

php -v

Sous Plesk, chaque version a son propre chemin, par exemple /opt/plesk/php/8.3/bin/php -v. La date de compilation (built:) aide à repérer les anciennes installations. Un serveur peut faire cohabiter une version corrigée et une ancienne version encore utilisée par un seul site oublié.

Que faire selon votre situation

Votre version a un correctif : installez-le, puis redémarrez PHP. Testez ensuite vos formulaires et votre parcours de paiement.

Votre site est bloqué sur une ancienne version : c’est le cas le plus risqué, et une mise à jour de sécurité ne suffira pas. La vraie sortie reste la migration vers une version maintenue. Faites-la d’abord sur une copie du site, car une extension, un module ou du code ancien peut ne pas la supporter. Pensez aussi à la suite : PHP 8.2 cessera d’être maintenu le 31 décembre 2026.

Vous ne pouvez pas migrer tout de suite : réduisez l’exposition en attendant. Le projet PHP propose des réglages provisoires, à appliquer au niveau du serveur, puis à suivre d’un redémarrage :

session.upload_progress.enabled=0
memory_limit=-1
post_max_size=8M

Utilisez post_max_size=32M si votre site reçoit des fichiers. Le projet PHP est clair : ces réglages réduisent le risque sans rendre l’installation sûre. Un pare-feu applicatif peut aussi aider, mais la CISA le présente comme une protection temporaire. Si un site ancien ne sert plus, le plus simple reste de le couper.

Et si votre site a déjà été visé ?

Corriger PHP ne retire pas ce qu’un attaquant aurait déjà installé. Recherchez notamment :

• des fichiers PHP récents que personne n’a déposés ;
• des tâches planifiées ou des comptes inconnus ;
• des processus PHP qui lancent un shell ou téléchargent des outils, le comportement que la CISA recommande de surveiller.

Si vous trouvez quelque chose, conservez les journaux et n’effacez rien dans la précipitation. Changez aussi les mots de passe et les clés utilisés par le site, depuis un poste sain. Notre page sur la réponse aux incidents de cybersécurité détaille notre intervention.

À quoi faire attention ensuite

Le projet PHP a annoncé une troisième faille, CVE-2026-115560, dont le correctif arrivera avec la prochaine version régulière. Elle ne concerne qu’une combinaison de réglages peu courante, mais elle rappelle qu’une version corrigée doit être suivie dans le temps.

Votre CMS demande le même suivi : WordPress vient par exemple de corriger 22 failles dans sa version 7.1.4.

Pour faire le point, consultez notre page développement PHP pour une migration, notre maintenance de site WordPress, nos applications métier Laravel ou notre page cybersécurité.

Sources : annonce du projet PHP, alerte du CERT-FR et alerte de la CISA.