PHP2Shell : votre site PHP est-il sûr ? Corrigez-le

PHP2Shell est le nom donné aux vulnérabilités critiques de PHP divulguées le 21 octobre 2026. Si votre site utilise PHP, la question immédiate est de savoir si l’environnement d’exécution qui répond aux visiteurs dispose des correctifs de sécurité. Une extension mise à jour ou un tableau de bord de pare-feu au vert ne suffit pas à le démontrer.

PHP2Shell touche l’environnement PHP sous-jacent aux sites et peut permettre l’exécution de code à distance sans authentification. PHP a publié les correctifs 8.2.35, 8.3.36, 8.4.27 et 8.5.12, et vous devez vérifier qu’une version corrigée ou un rétroportage documenté du fournisseur est effectivement utilisé pour servir les requêtes web. Conservez les protections défensives, mais ne considérez pas un WAF ou un réglage temporaire comme un remplacement du correctif.

État vérifié le 21 octobre 2026 à 17:15 UTC. Ce guide tient compte des correctifs publiés, et non de l’annonce antérieure indiquant qu’une version était encore attendue. Consultez de nouveau les avis liés avant toute modification, car les paquets des fournisseurs et les recommandations peuvent évoluer rapidement.

PHP2Shell : qu’est-ce qui a réellement été confirmé ?

L’équipe de sécurité PHP identifie deux failles pouvant permettre l’exécution de code à distance sans connexion préalable. Son avis officiel indique que les installations PHP traitant des requêtes web sont exposées et présente Apache avec mod_php comme la configuration la plus risquée. L’environnement d’exécution, sa compilation et le traitement des requêtes influencent l’exploitabilité.

Les deux avis affichent un score CVSS v4.0 de 9.2. Lisez les rapports de référence concernant CVE-2026-109618 et CVE-2026-109619 , plutôt que de vous fier à une solution provisoire proposée sur un réseau social.

C’est une raison d’agir rapidement, pas la preuve que tous les sites PHP ont déjà été compromis. Une vulnérabilité critique, une tentative d’attaque et une intrusion confirmée constituent des constats différents. Votre réponse doit déterminer lesquels concernent vos propres systèmes.

Quelles versions de PHP corrigent PHP2Shell ?

Les versions de sécurité publiées aujourd’hui pour les branches prises en charge figurent ci-dessous. Ce tableau sert de point de départ pour vérifier une installation issue du projet PHP. Les paquets d’une distribution peuvent intégrer les correctifs sous une révision différente.

Ces versions sont confirmées dans les annonces de publication PHP . Si votre distribution ou votre hébergeur fournit des rétroportages, demandez son avis de sécurité et la révision exacte du paquet installé. Un simple numéro de version peut faire classer à tort un paquet fournisseur corrigé ou un environnement embarqué obsolète.

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour normales du projet d’origine. PHP a également fourni des rétroportages minimaux sous forme de code source pour 7.4, 8.0 et 8.1, sans rétablir pour autant leur prise en charge continue. Obtenez un correctif pris en charge par un fournisseur clairement responsable ou préparez une montée de version. Le tableau de prise en charge PHP présente le statut actuel des branches.

Vérifiez séparément les conteneurs, les installations PHP embarquées et les équipements applicatifs. Les recommandations opérationnelles du NCSC-NL soulignent que la mise à jour du PHP de l’hôte ne met pas nécessairement à jour ces environnements.

WordPress, Laravel et les autres sites PHP sont-ils concernés ?

Commencez par l’interpréteur qui exécute l’application. Un site WordPress, une application Laravel et un portail PHP sur mesure peuvent partager un environnement obsolète alors que leur code applicatif diffère totalement. Installer le dernier thème, la dernière extension ou la dernière version du framework n’installe pas le correctif de sécurité de PHP.

Sur un hébergement géré, demandez quelle version PHP ou quel paquet corrigé sert chaque site, si le changement a atteint tous les nœuds et si les processus ont été redémarrés lorsque nécessaire. Exigez des éléments issus de la plateforme d’hébergement plutôt que de prendre une notification de mise à jour applicative pour une confirmation.

Sur vos propres systèmes, inventoriez aussi les sites secondaires, interfaces d’administration, anciens hôtes virtuels et environnements de prévisualisation. L’application de production peut être corrigée alors qu’un ancien site reste accessible publiquement sur la même infrastructure. Attribuez un responsable et une décision de traitement à chaque environnement exposé.

Ne déduisez pas qu’un formulaire de téléversement inutilisé rend l’installation sûre. Les avis PHP décrivent des chemins de traitement des requêtes dans l’environnement d’exécution. Les fonctions visibles par le visiteur ne constituent pas une évaluation complète de l’exposition.

Corriger et vérifier l’environnement qui sert les visiteurs

Établir ce qui s’exécute réellement

Identifiez l’intégration au serveur web, le paquet PHP ou l’image du conteneur, la source de configuration et le responsable du service. Reliez cet inventaire au nom d’hôte utilisé par les clients. Un ingénieur contrôlant le mauvais serveur peut produire un rapport de version convaincant mais sans pertinence.

Ces commandes en lecture seule identifient l’installation en ligne de commande et sa configuration :

1php -v
2php --ini

Elles ne prouvent pas ce qu’exécutent PHP-FPM, Apache ou une autre intégration web. Utilisez les informations d’hébergement accessibles après authentification ou un contrôle administratif encadré pour établir l’environnement réellement utilisé. Ne laissez pas de page de diagnostic publique exposer la configuration et les détails de l’environnement.

Pour un déploiement en conteneurs, vérifiez l’image et l’instance applicative qui reçoivent effectivement le trafic, pas seulement l’image de remplacement présente dans un registre. Incluez toutes les instances derrière l’équilibreur de charge et les éventuels services de traitement distincts dans le compte rendu de modification.

Appliquer le correctif pris en charge et tester l’application

Suivez la procédure de mise à jour documentée par la source de paquets maintenue ou le fournisseur de l’image. Consignez la révision installée et l’avis du fournisseur couvrant les deux CVE. Planifiez les redémarrages ou remplacements d’instances adaptés au déploiement, sans supposer que télécharger un paquet modifie les processus en cours.

Préservez les journaux pertinents avant toute modification perturbatrice. Disposez d’une sauvegarde vérifiée et d’un plan de reprise, puis testez des parcours applicatifs représentatifs après la mise à jour. La connexion, les sessions, le paiement, les téléversements et les traitements en arrière-plan sont des candidats utiles lorsque l’application les utilise.

Terminez en contrôlant de nouveau l’environnement qui traite les requêtes. Conservez les preuves des instances mises à jour, du moment où le trafic a basculé et de la personne ayant accepté les contrôles applicatifs. Une tâche de déploiement réussie est utile, mais ne constitue pas toute la vérification.

Le WAF Cloudflare protège-t-il contre PHP2Shell ?

Cloudflare annonce avoir déployé des protections WAF contre PHP2Shell pour les clients WAF gratuits et payants et avoir observé du trafic d’attaque. Son annonce décrit des protections analysant les informations des requêtes et des réponses. Elle recommande aussi explicitement de corriger PHP malgré ces protections.

Pour un site donné, confirmez que le trafic concerné passe réellement par le service protégé et que les règles applicables sont activées. Examinez les exceptions, les règles de contournement et toute origine accessible séparément. Ce sont des contrôles de déploiement, pas l’affirmation que l’annonce de Cloudflare garantit la protection de chaque chemin possible vers votre application.

Conservez les événements WAF pour l’enquête. Une requête bloquée peut établir qu’une règle a détecté cette requête. Elle ne peut certifier que l’origine n’a jamais été atteinte autrement ou qu’aucune intrusion antérieure n’a eu lieu.

Utilisez le WAF comme couche défensive supplémentaire pendant la mise à jour de l’environnement PHP. Ne reportez pas le correctif simplement parce que le tableau de bord enregistre des tentatives bloquées.

Les mesures temporaires ne corrigent pas entièrement PHP2Shell

Si l’application du correctif est temporairement bloquée, suivez les avis PHP actuels avec l’ingénieur ou le prestataire responsable du système. L’avis relatif à l’état périmé explique pourquoi la désactivation de session.upload_progress.enabled doit intervenir avant l’analyse des requêtes et nécessite le redémarrage des processus. Il avertit expressément de ne pas compter sur ini_set() ou sur .user.ini avec FPM pour cela.

Ce changement bloque les chemins confirmés liés aux sessions, pas toutes les variantes. PHP 8.5 dispose aussi de recommandations distinctes concernant fatal_error_backtraces. Copier quelques lignes de configuration depuis un forum ne prouve pas que les deux vulnérabilités sont traitées.

L’avis relatif à l’épuisement de mémoire décrit d’autres contrôles, dont les limites des requêtes et les changements de gestion des limites mémoire. Ils ont des conséquences sur les ressources et la disponibilité. Examinez les instructions complètes adaptées au déploiement plutôt que de supprimer à la légère les limites mémoire d’un serveur en production.

Si l’exposition ne peut être réduite de façon acceptable avant le correctif, envisagez avec les responsables de restreindre l’accès public à l’application touchée. Documentez la mesure temporaire, ses limites, son responsable et la correction définitive prévue. Une solution provisoire doit avoir une condition de retrait ou de réexamen, plutôt que devenir un réglage permanent non documenté.

Que surveiller après l’évaluation de l’exposition ?

Établissez d’abord un état de référence et préservez la période pertinente. Corrélez les requêtes web avec les événements PHP, du serveur web et de l’hôte, plutôt que de considérer une requête inhabituelle isolée comme un diagnostic complet. Si des journaux manquent, consignez explicitement cette limite.

Ce sont des pistes d’enquête, pas des indicateurs propres à PHP2Shell ni des preuves de compromission. Des opérations normales peuvent produire des symptômes similaires. Inversement, l’absence d’alertes ne prouve pas qu’un système non corrigé était sûr.

Si des éléments suggèrent une intrusion, préservez-les et organisez la gestion de l’incident parallèlement à la correction. Mettre l’interpréteur à jour ne supprime pas la persistance d’un attaquant, n’annule pas le vol d’identifiants et n’établit pas quelles données ont été consultées. Traitez ces questions séparément dans le plan de réponse.

Questions fréquentes

Qu’est-ce que l’exploit PHP2Shell ? PHP2Shell désigne les vulnérabilités PHP suivies sous CVE-2026-109618 et CVE-2026-109619. Elles concernent la gestion de mémoire de l’environnement d’exécution et peuvent permettre l’exécution de code à distance sans authentification. Il ne s’agit pas simplement d’un défaut d’extension WordPress.

Quelles versions vérifier pour le correctif PHP2Shell ? Les correctifs des branches prises en charge publiés le 21 octobre 2026 sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les rétroportages des distributions, obtenez l’avis du fournisseur et confirmez la révision exacte du paquet corrigé installé dans l’environnement qui sert les requêtes.

La mise à jour de WordPress corrige-t-elle PHP2Shell ? Mettre WordPress à jour ne met pas à jour son interpréteur PHP sous-jacent. Maintenez l’application à jour, mais vérifiez séparément le correctif de sécurité PHP avec votre hébergeur ou l’ingénieur responsable du serveur.

Un site derrière Cloudflare est-il automatiquement sûr ? Cloudflare annonce des protections WAF, mais le trajet du trafic, les règles applicables et l’exposition de l’origine doivent encore être vérifiés. Conservez les protections et corrigez PHP. Un tableau de bord de pare-feu ne prouve ni la correction de l’environnement ni l’absence de compromission antérieure.

Désactiver le suivi de progression des téléversements suffit-il ? Non. PHP présente cette mesure comme un blocage des chemins confirmés liés aux sessions, pas de toutes les variantes. Elle doit être appliquée au bon niveau de configuration avec redémarrage des processus. Un environnement corrigé ou un rétroportage fournisseur vérifié reste nécessaire.

Puis-je tester un exploit public contre mon site en production ? Privilégiez d’abord les preuves concernant la version, les paquets et la configuration. Si la validation nécessite un test d’exploitation, encadrez-le par une autorisation explicite dans un environnement contrôlé avec isolation, surveillance et plan de reprise. N’exécutez pas de scripts d’exploitation non examinés en production.

Le correctif prouve-t-il que le serveur n’a pas été compromis ? Non. Le correctif traite les failles de l’environnement d’exécution, tandis que l’analyse d’incident examine l’activité antérieure, la persistance, les identifiants et les éventuels accès aux données. Coordonnez ces travaux et consignez les limites des preuves disponibles.

Besoin d’aide pour vérifier, surveiller ou corriger votre site PHP ?

Nous pouvons déterminer quels environnements PHP servent vos sites, évaluer l’exposition, examiner les journaux et protections disponibles, et préparer le correctif ou la montée de version prise en charge. Si une observation continue est nécessaire, nous pouvons définir un périmètre de surveillance, les responsables des alertes et une procédure d’escalade adaptée aux risques constatés.

Notre service de sécurité applicative accompagne l’évaluation et l’investigation, tandis que notre service de sécurité des serveurs couvre l’hébergement et la configuration. Nous pouvons travailler avec votre hébergeur pour vérifier ses correctifs, coordonner les modifications et documenter les contrôles applicatifs après mise à jour.

Le résultat utile est un compte rendu clair de ce qui a été vérifié et corrigé, des incertitudes restantes et des responsables du suivi. Nous ne promettons pas un certificat de sécurité sur la base d’un numéro de version ou d’un seul scan. Le périmètre et la disponibilité sont convenus avant le début des travaux.

Contactez-nous pour vérifier votre exposition à PHP2Shell, surveiller la sécurité ou appliquer les correctifs . Précisez l’hébergement, les domaines concernés, les versions PHP connues et la personne autorisée à approuver les changements. N’envoyez pas de mots de passe ni de jetons d’accès dans votre première demande.