PHP2Shell éclate : pourquoi une vulnérabilité PHP pourrait-elle affecter la majorité des sites dans le monde ? Les utilisateurs ordinaires doivent-ils s’inquiéter ?

Le rapport de renseignement sur les menaces d’AWS indique que des tentatives d’exploitation de PHP2Shell ont été observées avant la divulgation publique dans l’environnement MadPot (rapport sur les observations d’exploitation). Cela confirme une activité observée dans un périmètre donné, mais ne prouve pas que la majorité des sites soit touchée. Cette semaine, si vous administrez un site, vérifiez les avis officiels et comparez-les aux composants, versions et réglages réellement déployés. Si vous utilisez simplement un site, consultez ses communications officielles et ne supposez pas que votre appareil est infecté.

Vous craignez pour vos comptes ou les services que vous consultez régulièrement ? Vous trouverez ici des gestes adaptés à votre situation.
Vous administrez un site PHP ? La méthode ci-dessous vous aidera à vérifier les conditions d’exposition avant d’agir.
Vous devez expliquer l’ampleur de l’événement ? Les repères suivants distinguent les faits confirmés des affirmations qui restent à démontrer.

Dernière mise à jour : 7 juillet 2026. Les faits ont été recoupés avec les avis de sécurité du projet PHP, des analyses techniques et des rapports d’observation d’activité.

PHP2Shell peut-elle toucher la majorité des sites dans le monde ?

Non, pas sur la seule base de la popularité de PHP. Pour établir que la majorité des sites est touchée, il faudrait connaître les versions concernées réellement déployées, les composants vulnérables présents, les configurations exposées et la proportion d’environnements répondant aux conditions d’exploitation. Une statistique sur l’usage de PHP ne fournit pas ces informations.

Les données de W3Techs portent sur l’utilisation de technologies Web selon la méthode présentée par cet organisme (indicateurs sur l’usage de PHP). Elles peuvent éclairer la diffusion du langage, mais ne mesurent ni les sites vulnérables à PHP2Shell ni les sites compromis. Le fait qu’un langage soit largement utilisé peut rendre une vulnérabilité pertinente pour de nombreux opérateurs ; il ne permet pas de déduire qu’elle s’applique à chacun d’eux.

Les avis de sécurité du projet PHP recensés dans les sources comprennent notamment deux avis distincts, GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp. Leur présence signifie qu’il faut examiner le contenu de chacun et son périmètre propre. Elle ne signifie pas que tous les sites utilisant PHP sont vulnérables. Les versions, conditions et recommandations associées à un avis ne doivent pas être attribuées automatiquement à l’autre.

L’analyse technique publiée par des chercheurs décrit PHP2Shell comme une vulnérabilité pouvant permettre l’exécution de code à distance lorsque les conditions techniques précisées sont réunies (analyse technique de PHP2Shell). Ce type de risque mérite une réponse rapide des équipes responsables des environnements concernés. Il ne prouve toutefois ni une exploitation réussie contre tous les sites PHP ni une compromission de tous leurs utilisateurs.

Il faut séparer trois catégories. La première comprend les sites qui utilisent PHP. La deuxième comprend ceux dont un composant, une version et une configuration correspondent à un avis de sécurité. La troisième rassemble les systèmes pour lesquels une exploitation a été confirmée. Ces catégories ne sont pas interchangeables : la première peut être très vaste alors que les deux autres restent limitées ou inconnues.

Indicateur observé	Ce qu’il permet d’établir	Ce qu’il ne permet pas de conclure
Utilisation de PHP	La présence du langage dans une population de sites définie par une méthode donnée	Que ces sites utilisent un composant vulnérable
Versions et réglages déployés	Si un environnement correspond aux conditions décrites dans un avis	Que l’attaque a réussi contre cet environnement
Tentatives détectées	Qu’une activité correspondant à certains critères a été observée dans un périmètre	Le nombre total de sites compromis dans le monde
Confirmation d’un incident	Qu’une organisation a établi une compromission dans son propre environnement	Que les autres sites PHP ont subi le même incident

À la date de cette vérification, les sources citées ne donnent pas de décompte mondial exhaustif des sites vulnérables ou compromis. Il n’est donc pas justifié d’affirmer que PHP2Shell touche « la majorité des sites dans le monde » sans étude documentant son échantillon, sa période de collecte, sa méthode et ses critères de confirmation.

Une vulnérabilité PHP : portée potentielle et conditions d’exposition

Une faille peut avoir une portée potentielle étendue lorsqu’un même composant est intégré à plusieurs applications ou environnements. Un site personnalisé, une extension ou un logiciel déployé par un hébergeur peuvent partager une dépendance. Si cette dépendance est concernée, plusieurs organisations doivent vérifier leurs installations. Mais cette possibilité ne signifie pas que tous ces systèmes soient exposés de la même manière.

Pour évaluer le risque, ne vous arrêtez pas au fait que PHP est installé. Vérifiez plutôt les éléments suivants :

Le composant précis. L’avis porte-t-il sur PHP lui-même, une extension, une bibliothèque ou une application construite avec PHP ? Le nom du langage ne suffit pas à identifier le logiciel vulnérable.
La version effectivement utilisée. Comparez la version en production à la plage affectée et aux versions corrigées indiquées par le mainteneur. Une version présente dans un dépôt n’est pas nécessairement celle qui s’exécute sur le serveur.
La configuration. Certaines conditions peuvent dépendre d’options ou de fonctions activées. Le réglage du poste de développement peut différer de celui de la production.
Le mode de déploiement. Une instance de secours, un ancien conteneur ou une application oubliée peut continuer à recevoir du trafic, même si l’environnement principal a été mis à jour.
Les prérequis d’exploitation. Un accès préalable, une interface accessible ou une requête particulière peuvent être nécessaires. Ces conditions doivent être établies à partir de l’avis ou d’une analyse vérifiable, et non supposées.

Les avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp doivent être lus séparément pour vérifier les versions, les conditions et les mesures recommandées. L’archive des annonces de sécurité PHP permet de recouper les communications du projet. En cas de divergence entre un résumé secondaire et l’avis du mainteneur, appuyez-vous sur l’avis correspondant au composant concerné et vérifiez si des mises à jour ultérieures l’ont modifié.

La différence entre exposition et compromission est tout aussi importante. Un système peut correspondre aux conditions de vulnérabilité sans qu’une attaque réussie soit établie. À l’inverse, une intrusion suspectée ne suffit pas à attribuer l’incident à PHP2Shell : il faut examiner les journaux, les versions installées et les éléments techniques disponibles. Une mise à jour corrige une faiblesse selon les indications du mainteneur ; elle ne prouve pas, à elle seule, qu’aucune exploitation antérieure n’a eu lieu.

Une alerte publiée, un système potentiellement vulnérable et une intrusion confirmée désignent trois situations différentes. Dans un rapport ou un message destiné à vos utilisateurs, retenez le niveau que vos éléments permettent réellement d’établir.

Des chiffres « mondiaux » : mesures à distinguer

Quand une publication affirme que « beaucoup de sites » ou « la majorité des sites » sont concernés, commencez par chercher ce qu’elle a compté. Le chiffre correspond-il à des sites utilisant PHP, à des installations dont la version est vulnérable, à des requêtes d’attaque ou à des compromissions confirmées ? Le dénominateur détermine ce que la donnée peut signifier.

Affirmation à vérifier	Informations nécessaires	Interprétation prudente
« La majorité des sites utilise PHP »	Population mesurée, méthode de détection, date et proportion de sites dont la technologie est identifiable	Indicateur d’adoption, pas mesure de vulnérabilité
« De nombreux sites sont vulnérables »	Composants, versions, configurations, échantillon et critères d’inclusion	Estimation de vulnérabilité si le périmètre est documenté
« L’exploitation est généralisée »	Définition d’une tentative et d’une compromission, période observée et méthode de déduplication	Activité détectée dans le périmètre étudié, sauf recensement plus large
« Des utilisateurs ont été touchés »	Confirmation d’incidents, nature des données concernées et communication des organisations	Preuve d’incidents dans les cas identifiés, pas décompte automatique de toutes les victimes

Cherchez également la date de collecte. Une mesure réalisée avant la publication d’un correctif ne décrit pas nécessairement la situation après son déploiement. Vérifiez si le rapport compte des domaines, des sous-domaines, des adresses IP, des serveurs ou des organisations ; une même organisation peut apparaître plusieurs fois selon la méthode. Assurez-vous enfin que le terme « attaque » ne regroupe pas indistinctement des balayages automatisés, des tentatives bloquées et des intrusions confirmées.

L’analyse technique des chercheurs et le rapport d’observation des menaces répondent à des questions différentes : l’une décrit le mécanisme et les conditions examinées, l’autre rapporte une activité observée dans son propre périmètre. Le rapport d’activité précoce ne doit pas être présenté comme une mesure mondiale si ses auteurs ne publient pas une telle méthode. De même, la description d’un mécanisme exploitable n’est pas une statistique de victimes.

Si une source ne publie ni méthode, ni période, ni échantillon, qualifiez son chiffre d’estimation non vérifiée ou ne le relayez pas. Évitez aussi de transformer une liste partagée sur les réseaux en liste confirmée de sites affectés. Une telle prudence protège les lecteurs contre une inquiétude injustifiée et permet aux équipes de sécurité de concentrer leur attention sur les systèmes qui répondent réellement aux critères de l’avis.

Utilisateurs ordinaires : risque et gestes utiles

Si vous consultez un site qui fonctionne avec PHP, cela ne signifie pas que votre téléphone ou votre ordinateur est infecté. PHP2Shell concerne le fonctionnement du côté serveur lorsque les conditions d’exposition sont réunies. Le niveau de risque pour vous dépend de l’état du service, des données qu’il conserve et de l’existence éventuelle d’un accès non autorisé. La correction du serveur relève de l’organisation qui exploite le site ou de son prestataire.

Votre réaction doit partir d’un signal concret. Consultez les annonces du service concerné depuis son application ou son site officiel. Si l’organisation confirme un incident et recommande de changer votre mot de passe, suivez ses instructions. Si vous observez une connexion inconnue, une modification de profil que vous n’avez pas faite ou un message de sécurité inhabituel, examinez le compte concerné sans utiliser les liens reçus dans un message suspect.

Vous pouvez suivre ces gestes proportionnés :

Vérifiez les notifications officielles du service que vous utilisez régulièrement.
En cas de connexion inconnue, changez le mot de passe depuis le site ou l’application officiels et examinez les sessions actives si cette fonction existe.
Si vous avez réutilisé le même mot de passe sur d’autres services, remplacez-le également sur ces comptes et choisissez des mots de passe distincts.
Activez la validation en plusieurs étapes lorsqu’elle est proposée.
Surveillez les messages liés à la récupération du compte et les changements d’adresse électronique ou de numéro de téléphone.
Ne transmettez pas de listes de sites supposément touchés sans confirmation de leur exploitant ou d’une source technique vérifiable.

Ces précautions ne signifient pas que PHP2Shell a compromis votre compte. Elles s’appliquent lorsqu’un service confirme un incident ou lorsque vous constatez une anomalie. En l’absence de notification ou de comportement suspect, il n’y a pas de raison de conclure que vos données ont été volées simplement parce qu’un site utilise PHP.

Si votre service dépend d’un fournisseur, vérifiez les informations publiées par celui-ci ou demandez-lui de préciser le périmètre de son intervention. Vous pouvez consulter le centre d’aide Hashvps pour savoir où trouver les informations relatives à votre service. Pour toute question concernant la situation de votre propre service, vous pouvez également contacter Hashvps. Ces ressources ne remplacent pas l’avis technique du mainteneur du logiciel utilisé par le site concerné.

Sites PHP : méthode de vérification de l’exposition

Si vous administrez un site, votre objectif immédiat est de déterminer si l’environnement réel correspond aux conditions de l’avis. Évitez de traiter tous les serveurs comme identiques : les dépendances, les versions et les configurations peuvent varier entre les environnements de production, de secours et de test.

[ ] Inventoriez les environnements actifs. Recensez les serveurs qui reçoivent du trafic, les instances de secours, les conteneurs persistants et les tâches planifiées concernées. Incluez les composants gérés par un prestataire, même si vous ne contrôlez pas directement leur installation.
[ ] Identifiez le composant en cause. Relevez la version réellement exécutée et les dépendances chargées. Distinguez le langage, ses extensions et les applications qui l’utilisent.
[ ] Lisez l’avis qui correspond au composant. Vérifiez l’identifiant de l’avis, les versions affectées, les versions corrigées, les prérequis et les recommandations. Consultez les avis officiels du projet PHP et ses annonces de sécurité, plutôt qu’une commande copiée d’un article non vérifié.
[ ] Comparez avec la configuration de production. Confirmez les options activées, les interfaces accessibles et la façon dont le composant est appelé. Ne vous fiez pas uniquement au fichier de configuration d’un environnement de développement.
[ ] Appliquez la mesure recommandée. Installez la version corrigée ou suivez la mesure de réduction du risque explicitement indiquée par le mainteneur. Si une mise à jour doit être différée, consignez la raison, la mesure temporaire appliquée et la personne responsable.
[ ] Vérifiez le déploiement. Après intervention, confirmez que les processus actifs utilisent la version prévue. Une mise à jour du dépôt ne garantit pas que les processus en mémoire ou les conteneurs aient été remplacés.
[ ] Surveillez les éléments disponibles. Examinez les journaux et les alertes selon votre procédure habituelle. Si vous trouvez des signes d’activité suspecte, préservez les éléments utiles et déclenchez votre procédure de réponse à incident.

Cette liste fournit une méthode de vérification, pas une liste universelle de versions vulnérables ou de commandes de correction. Les plages de versions et les actions exactes doivent provenir de l’avis officiel applicable à votre installation. Ne transposez pas les détails d’un avis à un autre, même s’ils concernent le même langage ou une famille de composants proche.

Une réponse du type « PHP est à jour » peut être insuffisante. Il faut savoir quelle version s’exécute, si le composant concerné est installé et si la configuration correspond au scénario décrit. Si l’application est fournie par un hébergeur ou un éditeur, demandez une confirmation explicite du composant vérifié et de la mesure appliquée. Conservez cette réponse avec la date et le périmètre, afin de pouvoir la réexaminer si l’avis évolue.

Enfin, séparez la correction de la vulnérabilité de l’enquête sur une éventuelle intrusion. Une mise à jour peut supprimer une condition d’exploitation, mais elle ne démontre pas que le serveur n’a pas été compromis auparavant. Si les journaux ou les alertes révèlent une activité suspecte, suivez votre procédure d’incident et évaluez les comptes ou données accessibles à l’application. Ne déclarez ni l’absence d’impact ni une compromission liée à PHP2Shell sans éléments suffisants.

Conclusions encore en attente

Les sources citées permettent d’affirmer qu’il existe des avis de sécurité à examiner, qu’une analyse technique décrit des conditions d’exploitation et qu’une activité a été observée dans un périmètre de surveillance avant la divulgation publique. Elles ne permettent pas, à elles seules, de déterminer le nombre mondial de sites vulnérables, le nombre total de victimes ou la proportion des sites PHP effectivement compromis.

La formule « la majorité des sites du monde » reste donc non établie par les éléments présentés ici. Elle ne devient crédible que si une étude expose son échantillon, sa période de collecte, ses critères de vulnérabilité et la distinction entre tentatives et compromissions confirmées. Si de nouvelles données apparaissent, il faudra les comparer à ces critères avant de modifier la conclusion.

En tant qu’utilisateur, vérifiez les notifications officielles des services que vous utilisez et réagissez à une alerte ou à une anomalie concrète. En tant qu’opérateur, confrontez les avis à vos composants, versions et réglages réellement déployés, puis suivez les recommandations du mainteneur. PHP étant répandu, la vérification est importante ; cette popularité ne suffit pas à conclure que PHP2Shell touche la majorité des sites.