PHP2Shell : deux failles critiques dans PHP, risques et correctifs

Pourquoi cette alerte PHP est-elle exceptionnelle ?

Le 20 octobre, l’équipe PHP annonçait une publication de sécurité urgente. Le 21 octobre, elle a livré les correctifs et rendu publics les détails techniques. Le CERT-FR et le CERT-EU recommandent une remédiation immédiate, voire l’isolement des services exposés à Internet lorsqu’aucun correctif ne peut être appliqué rapidement.

Les deux vulnérabilités appartiennent à la catégorie RCE (Remote Code Execution, ou exécution de code à distance). À la différence d’une erreur affectant une extension WordPress particulière ou une page d’application, elles se situent à l’intérieur du runtime PHP : celui-ci intervient dans le traitement des requêtes HTTP, des formulaires, de la mémoire et de l’état des processus.

« Sans authentification » ne signifie pas « compromis automatiquement ». L’attaque n’exige pas nécessairement de compte utilisateur, mais sa faisabilité varie selon le mode d’exécution et la configuration. La gravité réside dans le potentiel d’accès au système avant que les contrôles habituels de l’application aient pu jouer leur rôle.

Comprendre les deux vulnérabilités

Les défauts ont un point commun : des données internes sont utilisées alors que leur état mémoire n’est plus fiable. Ils exploitent toutefois deux mécanismes distincts.

Pourquoi les formulaires et les requêtes HTTP comptent

Dans la première faille, le traitement de certaines requêtes multipart, comme celles utilisées pour les formulaires et les fichiers envoyés au serveur, peut provoquer une pression mémoire inattendue. Dans la seconde, une erreur fatale ou certains diagnostics peuvent laisser subsister un état qui sera consommé lors d’une requête ultérieure. Les avis techniques de PHP détaillent ces familles de scénarios, sans qu’un formulaire vulnérable dans le code métier soit nécessaire dans tous les cas.

Pour Apache avec mod_php, l’équipe PHP considère le risque particulièrement élevé : une démonstration montre qu’une requête non authentifiée peut atteindre le chemin vulnérable avant toute exécution du code applicatif. PHP-FPM n’est pas pour autant hors de danger : le traitement des erreurs et les chemins d’exploitation ne sont pas identiques, mais PHP le classe également parmi les environnements concernés.

Une exploitation réussie peut permettre d’agir avec les privilèges du processus PHP : lire des fichiers accessibles au service, récupérer des secrets applicatifs, compromettre une base de données si ses identifiants sont disponibles, modifier du contenu ou perturber le service. L’étendue des conséquences dépend des permissions, de l’isolation et de l’architecture du serveur.

Quels sites, applications et environnements sont concernés ?

Le périmètre ne se limite pas aux sites qui affichent visiblement « PHP ». Une application peut utiliser PHP derrière un proxy, un CDN, un conteneur ou une plateforme managée. Le CERT-EU cite les principales interfaces web exécutant PHP : mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed.

Important : corriger WordPress, une extension ou une dépendance Composer ne corrige pas le moteur PHP. Inversement, un site au code applicatif correctement écrit peut rester exposé si son interpréteur n’a pas reçu le correctif.

Versions vulnérables et versions corrigées

Le CERT-FR considère les branches anciennes ainsi que toutes les versions antérieures aux correctifs suivants comme affectées :

Le projet PHP n’émet plus de versions officielles pour PHP 8.1 et les branches antérieures. Certains fournisseurs Linux et prestataires de support longue durée proposent néanmoins des correctifs rétroportés, sans changement de version majeure ou mineure. Un numéro ancien ne prouve donc pas à lui seul l’absence du correctif : il faut consulter les bulletins de la distribution et l’état du paquet installé.

PHP a aussi fourni des rétroportages minimaux de code source pour les branches 7.4, 8.0 et 8.1 ; cela ne signifie pas qu’elles retrouvent un support standard. PHP 8.2 atteint sa fin de vie le 31 décembre 2026 : sa correction immédiate doit idéalement s’accompagner d’un plan de migration.

Comment savoir si son site utilise une version vulnérable ?

La difficulté fréquente est de vérifier le bon PHP. Sur une même machine, la version lancée en terminal peut être différente de celle utilisée par Apache, PHP-FPM, un conteneur ou un sous-domaine. La vérification doit donc cibler le service web réellement en production.

Quelques commandes de diagnostic, à adapter au système :

php -v
php --ini

php -v et php --ini décrivent l’environnement CLI, pas nécessairement celui qui traite les requêtes HTTP. Pour PHP-FPM, vérifier le binaire du pool concerné, ses fichiers de configuration et le service réellement lancé. Pour Docker ou Kubernetes, contrôler à la fois l’image reconstruite et les conteneurs ou pods actifs. Ne laissez jamais une page phpinfo() accessible publiquement pour effectuer ce contrôle.

En présence d’indices sérieux de compromission, une mise à jour n’efface pas nécessairement un accès malveillant déjà obtenu. Il faut alors isoler le système touché, préserver les journaux, examiner les fichiers et secrets exposés et appliquer une procédure de réponse à incident adaptée.

Que faire si une mise à jour immédiate est impossible ?

PHP insiste sur ce point : aucune mesure de contournement n’apporte une protection complète. Le CERT-EU recommande d’envisager l’isolement temporaire des services publics dont la correction ne peut pas être appliquée et vérifiée.

À titre d’exemple, le CERT-FR mentionne la désactivation de la progression des téléversements de session via session.upload_progress.enabled=Off et, selon les cas, un filtrage du trafic multipart. Le projet PHP cite également des ajustements liés à memory_limit pour limiter certains chemins de la première faille. Ces adaptations sont partielles et parfois délicates à exploiter de manière sûre : elles doivent être décidées par l’administrateur responsable, contrôlées sur l’ensemble des processus et supprimées ou réévaluées après installation des correctifs.

Évitez de conclure à l’absence de risque simplement parce qu’un WAF est actif, qu’un scanner externe ne détecte rien ou que les erreurs PHP ne sont pas affichées dans le navigateur. Aucun de ces constats ne prouve que la mémoire du runtime est corrigée.

Questions fréquentes pour les propriétaires de sites

Mon site WordPress est à jour : suis-je protégé ?

Pas nécessairement. WordPress et ses extensions sont des composants distincts du moteur PHP. Il faut mettre à jour chacun de ces niveaux et vérifier en particulier la version de PHP réellement utilisée par le site.

Mon site utilise Nginx et PHP-FPM : suis-je moins exposé ?

Le chemin d’exploitation démontré avec mod_php est particulièrement préoccupant, mais PHP inclut aussi PHP-FPM parmi les environnements à corriger. Le niveau de risque est différent d’une architecture à l’autre ; il ne faut pas assimiler « moins directement démontré » à « non vulnérable ».

Je suis en hébergement mutualisé : qui agit ?

L’opérateur gère souvent le moteur PHP, mais les responsabilités dépendent du contrat et de l’offre. Demandez la confirmation du correctif, consultez les notifications de maintenance et effectuez les vérifications fonctionnelles de votre site.

Mon application est dans Docker : une mise à jour du serveur suffit-elle ?

Non si PHP est embarqué dans les images applicatives. Il faut reconstruire les images à partir d’une base corrigée, redéployer tous les réplicas et vérifier qu’aucune ancienne instance ne reste en production.

Existe-t-il déjà des attaques ?

Le CERT-EU indique le 21 octobre que des démonstrations de faisabilité circulent publiquement, ce qui accroît la probabilité d’attaques. Ce constat ne permet pas d’affirmer qu’un site donné a été compromis. Pour les services exposés, la priorité reste la correction rapide et la surveillance des journaux.

Une simple commande de mise à jour suffit-elle ?

Elle constitue une étape, pas une preuve finale. Il faut vérifier la bonne source de paquets, la mise à jour de toutes les instances, le redémarrage effectif des processus et le fonctionnement de l’application après déploiement.

Ce que cette alerte change pour la sécurité des applications web

PHP2Shell rappelle une réalité souvent négligée : la sécurité d’un site ne dépend pas uniquement de la qualité du code métier, des extensions installées ou du framework. Elle dépend aussi du moteur qui exécute ce code, de la gestion de sa mémoire et de la discipline de mise à jour des environnements de production.

La bonne stratégie est donc concrète : inventorier, corriger, redéployer, vérifier et surveiller. Les organisations qui ne peuvent pas appliquer rapidement les correctifs doivent arbitrer explicitement le maintien de leurs services exposés à Internet.

Sources et documentation de référence

Article fondé sur les bulletins publics du 21 octobre 2026. Les consignes de remédiation peuvent être complétées par les mainteneurs et les fournisseurs des distributions.

Consulter les avis officiels 5 références

• PHP — avis de sécurité du 21 octobre 2026 et versions corrigées.
• PHP / GitHub — CVE-2026-109618, corruption lors d’un dépassement de mémoire.
• PHP / GitHub — CVE-2026-109619, état global périmé.
• CERT-FR — alerte et mesures de réduction d’exposition.
• CERT-EU — Security Advisory 2026-018.