Faille PHP2Shell : ce que les entreprises doivent faire cette semaine

Le 21 octobre 2026, l’équipe de PHP a publié en urgence les correctifs de deux failles critiques, surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un attaquant, sans identifiant ni mot de passe, d’exécuter du code sur le serveur qui héberge votre site. Les premières attaques ont été observées avant même l’annonce officielle. Si votre site vitrine, votre intranet ou une application métier tourne sous PHP, c’est cette semaine qu’il faut agir.

Ce qui s’est passé

PHP est le langage qui fait fonctionner la grande majorité des sites web : WordPress, Joomla, Drupal, Magento, Laravel, mais aussi de nombreux logiciels de gestion développés sur mesure. Les deux failles touchent PHP lui-même, pas une extension ou un thème. Les mettre à jour ne suffit donc pas : c’est PHP qu’il faut corriger.

• CVE-2026-109618 : quand le serveur manque de mémoire au mauvais moment, PHP laisse des données à moitié préparées, puis les traite comme si elles étaient valides. Un attaquant peut provoquer cette situation et en profiter pour exécuter son propre code.
• CVE-2026-109619 : PHP garde en mémoire des références vers des données déjà libérées. La requête suivante traitée par le même processus peut les réutiliser. Résultat possible : exécution de code, ou lecture de la mémoire du serveur, avec les mots de passe et clés d’accès qu’elle contient.

Les deux failles sont notées 9,2 sur 10 (CVSS 4.0). Les pièges d’Amazon ont détecté une première tentative d’exploitation le 17 octobre, quatre jours avant les correctifs. Cloudflare et plusieurs éditeurs de sécurité signalent depuis des attaques en cours.

Votre site est-il concerné ?

Très probablement, si vous n’avez pas encore mis PHP à jour depuis le 21 octobre. Selon l’équipe de PHP, toute installation qui répond à des requêtes web est exposée : PHP-FPM (le cas le plus courant avec nginx), Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec Apache mod_php, car l’attaque peut se déclencher avant même que votre application ne s’exécute. Le code en cause existe depuis PHP 5.4 : les vieux serveurs sont aussi touchés.

Votre site est chez un hébergeur ? Vous êtes concerné aussi : demandez-lui par écrit la version de PHP utilisée et la date de sa mise à jour.

Comment vérifier votre version

• Sous WordPress : Outils, puis Santé du site, onglet Informations, rubrique Serveur. La ligne « Version de PHP » doit afficher une version corrigée.
• Sur un serveur Linux : la commande php -v ne suffit pas, car elle peut afficher une autre installation que celle qui sert vos pages web. Vérifiez le paquet PHP-FPM ou le module Apache réellement utilisé.
• Distributions Ubuntu, Debian, Red Hat : elles corrigent parfois les failles sans changer le numéro de version. Fiez-vous au bulletin de sécurité de votre distribution, pas seulement au numéro affiché.

Les 5 actions à faire cette semaine

1. Mettre PHP à jour et redémarrer

C’est la seule vraie solution. Installez la version corrigée de votre branche, puis redémarrez tous les processus PHP (PHP-FPM ou Apache). Sans redémarrage, l’ancienne version continue de répondre.

2. Si la mise à jour doit attendre : appliquer les mesures temporaires

L’équipe de PHP propose des réglages qui réduisent le risque sans le supprimer : désactiver session.upload_progress.enabled, fixer la limite mémoire de façon que les applications ne puissent pas la modifier, et sous PHP 8.5 désactiver fatal_error_backtraces. Redémarrez PHP après chaque changement, et donnez-vous une date limite pour la vraie mise à jour.

3. Filtrer le trafic en amont

Cloudflare a déployé des règles de pare-feu applicatif (WAF) contre ces attaques, y compris pour l’offre gratuite. Elles ne protègent que le trafic qui passe réellement par Cloudflare : si l’adresse de votre serveur est connue, un attaquant peut le contacter directement. Un pare-feu FortiGate bien configuré limite aussi ce qui peut atteindre vos serveurs. Ces filtres font gagner du temps, ils ne remplacent pas la mise à jour.

4. Changer les mots de passe et clés d’accès exposés

L’une des deux failles permet de lire la mémoire du serveur. Si votre site est resté exposé sans correctif, considérez que ses secrets ont pu fuiter : mot de passe de la base de données, clés d’API (paiement, e-mail, CRM), clés de sécurité de WordPress. Changez-les après la mise à jour.

5. Surveiller les signes d’intrusion

Dans les jours qui suivent, regardez les journaux du serveur : plantages répétés de PHP, fichiers PHP inconnus dans les dossiers d’images ou de téléchargement, nouveaux comptes administrateurs, tâches planifiées que vous n’avez pas créées. Au moindre doute, isolez le serveur et faites appel à un spécialiste avant de le remettre en ligne.

Et la prochaine fois ?

Cette faille ne sera pas la dernière. Les entreprises qui ont réagi en quelques heures avaient trois choses en place : la liste à jour de leurs serveurs web et de leurs versions, des versions de PHP encore supportées, et quelqu’un chargé d’appliquer les mises à jour de sécurité chaque mois. C’est exactement ce que couvre une infogérance avec supervision 24/7 : les correctifs critiques sont appliqués sans attendre que vous lisiez l’actualité.

En résumé

PHP2Shell touche presque tous les sites et applications sous PHP, et les attaques ont déjà commencé. Vérifiez votre version aujourd’hui, mettez à jour PHP et redémarrez-le, changez les secrets exposés, puis surveillez vos journaux. Si vos serveurs tournent sous PHP 8.1 ou plus ancien, c’est le moment de planifier leur migration.

Sources : Tenable, FAQ PHP2Shell ; Qualys, analyse de PHP2Shell. Article mis à jour le 22 octobre 2026. Photo : Radowan Nakif Rehan sur Unsplash.