Faille PHP2Shell : ce que les entreprises doivent vérifier cette semaine

Le 21 octobre 2026, PHP, le langage sur lequel reposent environ 70 % des sites web, a publié en urgence la correction de deux failles critiques surnommées PHP2Shell. Le même jour, plusieurs préfectures et la CNIL ont coupé leurs sites par précaution. Cinq jours plus tard, les premières attaques réussies sont documentées.

Si votre site ou votre application tourne en PHP, et c'est le cas de WordPress, PrestaShop, Drupal, Magento, ou d'une application Laravel ou Symfony, voici ce que vous devez savoir et demander à votre prestataire.

L'essentiel en 30 secondes

• Le risque : un pirate peut prendre le contrôle du serveur qui héberge votre site, sans mot de passe, avec une simple requête web. Il peut ensuite lire vos données, celles de vos clients, ou s'en servir pour attaquer ailleurs.
• La cause : la faille est dans PHP lui-même, pas dans votre site. Mettre à jour WordPress ou vos extensions ne la corrige pas.
• La solution : mettre à jour PHP sur le serveur. C'est le travail de votre hébergeur ou de votre prestataire, encore faut-il qu'il l'ait fait.
• Le point d'alerte : les versions anciennes de PHP (8.1 et antérieures) restent vulnérables et ne recevront pas de correctif officiel.

Vous ne savez pas où en est votre application ? Nous l'auditons gratuitement, avec des résultats sous 48 h : demander mon audit PHP gratuit.

Que s'est-il passé ?

Ces premières attaques réussies visaient des serveurs volontairement exposés, dans une configuration favorable aux pirates. Elles ne veulent pas dire que tous les sites PHP sont piratés. Elles prouvent en revanche que l'attaque fonctionne, et qu'il faut désormais raisonner en jours, pas en semaines.

Suis-je concerné ?

Vous êtes concerné si un de vos sites, une de vos applications ou un de vos équipements utilise PHP, ce qui est très fréquent. La version de PHP détermine ce qu'il faut faire :

C'est la dernière ligne qui pose problème. Beaucoup d'applications d'entreprise tournent encore en PHP 7.4 ou 8.0, sur un serveur que plus personne n'ose toucher. Et PHP n'est pas seulement dans vos sites : il équipe aussi les interfaces d'administration de nombreux NAS, pare-feu et logiciels métier.

Les cinq questions à poser à votre prestataire

Vous n'avez pas besoin d'être développeur pour vous assurer que le travail est fait. Posez ces questions à votre hébergeur, votre agence ou votre équipe technique, par écrit :

1. Quelles sont toutes nos applications qui utilisent PHP ? Site vitrine, boutique, extranet, outil interne, ancien site de campagne, site de test… Ce sont souvent les oubliés qui sont attaqués.
2. Dans quelle version de PHP tourne chacune d'elles ?
3. Le correctif est-il installé, et comment l'avez-vous vérifié ? Sur certains serveurs, le numéro de version ne change pas après correction : une réponse du type « on est en 8.3 » ne suffit pas.
4. Pour celles qui ne peuvent pas être corrigées, quelles protections avez-vous mises en place, et quand migrons-nous ?
5. Avez-vous vérifié qu'aucun serveur n'a été compromis ? En cas de doute, un serveur doit être reconstruit plutôt que « nettoyé », et les mots de passe et clés d'accès renouvelés.

Si une de ces réponses prend plus de deux jours à obtenir, c'est en soi une information sur la maîtrise de votre système.

Le détail technique, pour votre équipe

Cette partie s'adresse à la personne qui administre vos serveurs. Vous pouvez la lui transmettre.

• Vulnérabilités : CVE-2026-109618 (corruption mémoire sur dépassement de memory_limit) et CVE-2026-109619 (état global obsolète menant à un use-after-free). Score 9,2 (CVSS v4.0). Exploitation non authentifiée, exécution de code avec les droits du worker web.
• Modes touchés : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Risque maximal avec mod_php, où l'exploit se déclenche avant l'exécution du code applicatif.
• Correction : PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35, puis redémarrage des workers et du serveur web. En conteneur, reconstruire les images. Pour 7.4 à 8.1 : correctifs source minimaux publiés par PHP ou rétroportages de la distribution. Sur Debian et Ubuntu (dépôt Sury notamment), vérifier la révision du paquet avec dpkg -l | grep php, pas seulement php -v.
• Mesures temporaires, qui réduisent le risque sans le supprimer : session.upload_progress.enabled = 0, post_max_size réduit au strict besoin, memory_limit verrouillé et limite mémoire au niveau du conteneur ou du cgroup, fatal_error_backtraces = 0 en PHP 8.5, règles WAF de votre fournisseur. Redémarrer les workers après modification.
• Détection : rechercher des requêtes multipart inhabituelles portant un marqueur PHP_SESSION_UPLOAD_PROGRESS, des cookies PHPSESSID anormalement longs en réponse, et des processus shell lancés par l'utilisateur du serveur web.

Corriger, mettre à niveau ou reconstruire ?

Cette crise révèle une question que beaucoup d'entreprises repoussent : l'application est-elle encore saine, ou seulement tolérée ?

• Un site récent, bien maintenu : installer le correctif suffit.
• Une application ancienne en PHP 7.4 ou 8.0 : un correctif provisoire peut dépanner, mais le problème reviendra à la prochaine alerte. Une montée de version planifiée est préférable. Notre checklist d'audit technique aide à en évaluer l'effort.
• Un site WordPress lent, chargé d'extensions, que plus personne ne met à jour : la bonne question n'est plus « comment le sécuriser ? » mais « faut-il le garder ? ». Lisez optimiser ou refaire un site WordPress. Si la reconstruction est la bonne option, nous la réalisons sans perdre votre référencement : c'est notre offre de migration de site WordPress.
• Une application métier sans équipe pour s'en occuper : c'est le rôle de la maintenance applicative (TMA), ou d'un CTO externalisé pour piloter les décisions.

Dans tous les cas, une correction de sécurité qui met des semaines à être appliquée est le signe d'une dette DevOps. L'enjeu n'est pas seulement de corriger PHP2Shell, mais d'être capable de corriger la prochaine faille en quelques heures.

Ce que nous vous proposons

Nous savons répondre rapidement, et en termes clairs, aux questions qui précèdent toute action* :

• quelles applications PHP avez-vous réellement, et dans quelle version ?
• lesquelles sont exposées, lesquelles ne sont plus maintenues ?
• que faut-il corriger tout de suite, mettre à niveau ce trimestre, ou reconstruire ?

C'est l'objet de notre audit PHP gratuit en 48 h. Vous nous indiquez l'adresse de votre site ou de votre application ; un CTO vous rappelle sous 24 h, et vous recevez sous 48 h ouvrées une synthèse claire et vos priorités. C'est 100 % gratuit et sans engagement.

Demander mon audit gratuit en 48 h

* Farrago n'est pas un cabinet de test d'intrusion : cet audit ne constitue pas une certification de sécurité.

Sources

• Alerte officielle, versions affectées et recommandations : CERT-FR — CERTFR-2026-ALE-014.
• Première exploitation réussie : 01net et le rapport d'Adel Karimi.
• Campagne de reconnaissance et autres tentatives : The Hacker News et CYFIRMA.
• Calendrier, correctifs et mesures temporaires : BleepingComputer, IT-Connect.
• Premières tentatives avant correctif : BleepingComputer — Amazon.
• Sites publics français mis en maintenance : Selectra.

Les informations évoluent vite : vérifiez toujours l'avis officiel du projet PHP avant d'agir sur un système en production.