.svg)
En résumé. Deux failles critiques (CVSS 9,2) dans le moteur de PHP permettent à un attaquant d'exécuter du code sur un serveur, sans compte ni mot de passe. Des correctifs d'urgence ont été annoncés le 21 octobre pour les versions encore supportées, et la mauvaise nouvelle touche les PME qui font tourner d'anciennes versions de PHP sans le savoir : un vieux site WordPress, un extranet ou un logiciel métier hébergé.
What Happened
Les détails de deux vulnérabilités du cœur de PHP ont fuité avant la divulgation coordonnée. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et le nom informel de PHP2Shell. Les deux sont notées 9,2 sur 10 et relèvent de la même famille de défauts mémoire (use-after-free). Le premier se situe dans la gestion de la progression des envois de fichiers, le second dans le traitement de certaines erreurs fatales.
Selon l'éditeur de sécurité Sansec, un code d'exploitation public existe et Cloudflare aurait observé des tentatives dès le matin du 21 octobre, avant même la publication des correctifs. Ce point n'est pas encore confirmé par toutes les sources, mais il justifie de ne pas attendre. Le projet PHP a annoncé des correctifs d'urgence le 21 octobre à 14h UTC pour les branches supportées. Les branches en fin de vie (8.1 et antérieures, y compris 7.x et 5.x) ne recevront pas de correctif officiel. Le code fautif date de PHP 5.4, sorti en 2012, ce qui donne une idée de l'étendue du parc concerné.
Un point de nuance : la configuration par défaut est exposée, mais l'exploitation demande des requêtes d'envoi de fichiers très particulières et reste délicate à réussir de façon fiable. Ce n'est pas une raison de relâcher l'attention, seulement de rester factuel. Les mesures de contournement connues sont partielles, et Sophos indique à ce stade ne pas avoir de contournement officiel à proposer.
Does this apply to me?
Vous l'êtes si une application PHP est accessible depuis Internet chez vous ou chez un prestataire. Cela couvre beaucoup de cas : le site vitrine sous WordPress ou Joomla, un portail client, un extranet, un outil de réservation, un ancien intranet que personne n'ose arrêter. Les environnements Microsoft purs, sans PHP exposé, sont peu touchés. Mais beaucoup de PME découvrent un serveur PHP oublié dans un coin, ou hébergé chez un agence web dont elles ne connaissent pas la version.
Pour le savoir, posez trois questions à votre hébergeur ou à votre agence : quelle version de PHP tourne sur chacun de nos sites, est-elle encore supportée, et quand le correctif sera-t-il appliqué ? Si la réponse est PHP 8.1 ou plus ancien, le risque est plus élevé, car aucun correctif officiel n'est prévu.
What to Do Now
1. Faire l'inventaire (aujourd'hui). Listez les sites et applications PHP exposés sur Internet, avec leur version de PHP et leur hébergeur. Sans cette liste, impossible de prioriser.
2. Appliquer les correctifs sur les versions supportées (dès qu'ils sont disponibles chez votre hébergeur). Les distributions et hébergeurs livrent les paquets à des rythmes différents, certains n'avaient pas encore publié le leur le 21 octobre. Demandez une date ferme plutôt qu'un « bientôt ».
3. Traiter les versions anciennes comme un sujet de fond. Demandez un correctif rétroporté à votre hébergeur, ou planifiez une migration vers une version supportée. En attendant, désactiver l'option session.upload_progress réduit une partie du risque, mais ne suffit pas à elle seule. Pour un site vitrine sans formulaire d'envoi de fichiers, restreindre temporairement les requêtes d'envoi côté serveur web est une option à évaluer avec votre prestataire, car elle peut casser des fonctions.
Si vous n'avez pas de ressource interne pour faire ce tri, c'est typiquement le type d'exercice que nous menons avec nos clients en infogérance : découvrir nos solutions.
Not sure about your exposure?
Get an update from an IT Systems expert
A quick assessment of your exposure and the steps you should take. No obligation.
In a nutshell
PHP2Shell mérite d'être traitée vite, mais avec méthode : inventaire d'abord, correctifs sur les versions supportées ensuite, plan de sortie pour les versions anciennes. Toutes les PME ne sont pas exposées de la même façon, et savoir où tourne PHP chez vous est déjà la moitié du travail. Si vous voulez un avis extérieur, nous pouvons vous aider à faire ce tri rapidement.
Frequently asked questions
Mon site WordPress est-il concerné ? Oui, s'il tourne sur un serveur PHP non corrigé, car la faille est dans PHP lui-même et non dans WordPress. Vérifiez la version de PHP auprès de votre hébergeur.
Un pare-feu applicatif (WAF) suffit-il ? Il peut réduire le risque en filtrant certaines requêtes, mais ne remplace pas le correctif. Les règles de protection sont encore en cours d'adaptation chez les éditeurs.
Faut-il couper mon site ? Pas systématiquement. Si le site gère des données sensibles et tourne sur une version ancienne sans correctif possible, une mise hors ligne temporaire ou un passage en lecture seule se discute avec votre prestataire.
— Samir Amara, CEO — IT Systèmes
.svg)