En bref : parmi les faits établis sur PHP2Shell figurent les deux numéros CVE, le score CVSS v4.0 de 9,2, les versions PHP corrigées et les mesures transitoires de php.net. Le niveau d'alerte orange du BSI (office fédéral allemand de la sécurité des technologies de l'information) est également établi. Ne sont pas établis : un score CVSS de 10, des attaques réussies confirmées à grande échelle et une liste d'indicateurs de détection. Qui distingue ces trois niveaux prend de meilleures décisions.
Pourquoi une vérification des faits sur PHP2Shell est nécessaire
Peu de failles de sécurité de ces dernières années ont généré aussi vite autant de gros titres. Avant même que l'équipe PHP ne publie les mises à jour le 21 octobre 2026, des messages de forum, des captures d'écran et de prétendus détails circulaient, selon des rapports. Sont ensuite venus les avertissements des autorités, les blogs d'éditeurs, des décomptes de serveurs exposés et un flot de conseils.
Pour les exploitants, cela signifie que tous les chiffres et tous les conseils ne se valent pas. Une partie provient de sources primaires, une partie de reportages sérieux, une partie de spéculations. Cet article fait le tri parmi ce que vous pouvez retenir comme établi pour vos décisions. Les bases de la faille elle-même sont expliquées sur la page Qu'est-ce que PHP2Shell ?.
Le poids de chaque source
Un classement simple aide à lire chaque information :
- php.net : le projet PHP est la source primaire pour les numéros CVE, les évaluations, les modes d'exécution concernés, les versions corrigées et les mesures transitoires. La manière dont le projet traite les avis de sécurité en général est décrite dans notre article sur le processus de sécurité de PHP.
- Autorités : le BSI fournit l'évaluation de la situation en Allemagne et des recommandations d'action ; CERT-EU et CERT-Bund (l'équipe de réponse aux urgences informatiques du gouvernement allemand) les complètent.
- Distributions et fournisseurs : Debian, Ubuntu, Red Hat, les hébergeurs et les services de plateforme ne se prononcent de manière fiable que sur leurs propres paquets et services.
- Sociétés de sécurité : Cloudflare, Unit 42, CybelAngel et d'autres rapportent à partir de leurs propres mesures. Précieux, mais chacun avec sa propre méthode.
- Médias et réseaux sociaux : utiles pour la rapidité, faibles sur les détails. Les affirmations qui en viennent ont besoin d'une confirmation de niveau supérieur.
Établi, rapporté, non prouvé : vue d'ensemble
Le tableau suivant classe les affirmations les plus fréquentes. « Établi » signifie : source primaire ou autorité. « Rapporté » signifie : issu des médias ou d'indications d'éditeurs, non confirmé de façon indépendante.
| Affirmation | Classement | Base |
|---|---|---|
| Deux failles, CVE-2026-109618 et CVE-2026-109619 | établi | php.net |
| Score CVSS v4.0 de 9,2, critique | établi | php.net |
| Score CVSS 10 | non défendable | selon des rapports, issu d'un message de forum avant l'annonce |
| Corrigé dans 8.5.12, 8.4.27, 8.3.36, 8.2.35 | établi | php.net |
| mod_php au risque le plus élevé, exploit démontré avant le code de l'application | établi | php.net |
| Presque toutes les versions jusqu'à PHP 5.4 concernées | rapporté | presse spécialisée |
| Première tentative d'attaque le 17.10. | rapporté | articles de presse citant Amazon |
| Plus de 22,6 millions d'instances exposées | rapporté | Unit 42, selon TechTarget |
| Attaques réussies à grande échelle | non prouvé | selon le BSI, non connues dans un premier temps |
| Indicateurs de compromission confirmés | n'existent pas | aucune publication |
| Les mesures transitoires protègent complètement | faux | php.net les qualifie expressément d'incomplètes |
Il est frappant de voir à quelle vitesse des chiffres prennent leur indépendance. Le score de 10,0 issu du message de forum est encore apparu des jours plus tard dans des articles, alors que l'équipe PHP avait depuis longtemps publié 9,2.
Où se situe réellement l'incertitude
La plus grande question ouverte n'est pas technique mais temporelle : que s'est-il passé entre la première tentative d'attaque rapportée et la correction sur chaque serveur ? Il n'existe pas de réponse générale. Cloudflare et Patchstack ont fait état de tentatives d'attaque, watchTowr a reproduit CVE-2026-109618 selon ses propres indications. Huntress, pour sa part, n'observait aucune attaque dans les environnements de ses partenaires au moment de son communiqué.
Ces affirmations ne se contredisent pas. Elles décrivent des angles différents : un grand service de proxy, une société de sécurité de plugins, une équipe de recherche et une entreprise disposant de sa propre base de clients. Il n'en ressort pas de tableau d'ensemble.
Même chose pour la question des versions concernées. Pour 8.2 à 8.5, la situation est claire. Pour les branches plus anciennes, il existe des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1, mais aucune version officielle. Ce qui précède est, selon la presse spécialisée, presque toujours concerné. Pour votre planification, cela ne change guère : un serveur sous PHP 8.1 ou plus ancien, sans rétroportage confirmé, doit être considéré comme exposé.
L'absence de preuves d'attaques n'est pas une preuve de sécurité. Comme il n'existe pas d'indicateurs de détection confirmés, une attaque contre un serveur donné ne peut être évaluée que par l'analyse du comportement, pas à l'aide d'une liste.
Ce que vous pouvez en déduire pour vos serveurs
Des faits établis découlent quelques étapes claires. Des faits non prouvés découle surtout la prudence.
- Vérifier le niveau de correctif : version corrigée ou rétroportage confirmé par le fournisseur. Le numéro de version affiché ne suffit pas à lui seul.
- Redémarrer tous les processus PHP : les nouveaux fichiers ne prennent effet que lorsqu'aucun ancien processus ne tourne plus.
- Sauvegarder les journaux à partir du 20.10. : la presse spécialisée le conseille afin qu'un examen ultérieur reste possible.
- Rechercher des traces : nouveaux fichiers PHP dans les dossiers d'envoi, tâches cron inconnues, processus du serveur web avec un shell. La page Suis-je déjà compromis ? vous guide dans cette vérification.
- Recouper les conseils : n'appliquer les conseils venus de forums et de réseaux sociaux que s'ils peuvent être rattachés à php.net ou à une autorité. L'article Faux conseils dangereux sur PHP2Shell recense les recommandations qui nuisent actuellement.
Pour la communication interne, la même séparation est utile. Qui présente à la direction « établi », « rapporté » et « ouvert » séparément évite à la fois l'alarmisme et la fausse alerte levée.
Comment PHP SOS aide-t-il concrètement ?
- Situation de vos systèmes : nous appliquons les faits établis à vos serveurs et distinguons dans la documentation ce qui a été mesuré, ce qui a été rapporté et ce qui reste ouvert.
- Correctif et preuve : nous vérifions l'état des paquets et le redémarrage de chaque service PHP et le consignons par écrit.
- Recherche de traces : nous sauvegardons les journaux à partir du 20 octobre et recherchons des comportements inhabituels, jusqu'à la clôture et la documentation de l'incident.
- Évaluation continue : nous évaluons pour vous les nouvelles informations avant qu'elles ne deviennent des mesures.
Le déroulement est décrit dans l'assistance immédiate PHP2Shell.
Conclusion
PHP2Shell est une affaire sérieuse, et cela est bien établi. C'est précisément pour cela qu'un regard sobre est utile : les sources primaires suffisent pour toutes les décisions importantes. Ce qui circule au-delà est souvent plus rapide que précis. Corriger, redémarrer, sauvegarder les journaux et rechercher des traces reste la réponse, quel que soit le chiffre qui circule en ce moment.
Questions fréquentes
PHP2Shell est-elle notée CVSS 10 ?
Non. Selon des rapports, le chiffre 10 provient d'un message de forum qui circulait avant l'annonce officielle. L'équipe PHP attribue aux deux failles un score CVSS v4.0 de 9,2. Cela reste la catégorie critique.
Existe-t-il une liste d'indicateurs permettant de reconnaître les attaques PHP2Shell ?
Pas jusqu'à présent. Aucun indicateur de compromission (IoC) confirmé n'a été publié. Pour vérifier si un serveur a été touché, il faut surveiller des comportements inhabituels, par exemple des processus du serveur web qui lancent un shell ou de nouveaux fichiers PHP dans les dossiers d'envoi (uploads).
Quelle est la source la plus fiable sur PHP2Shell ?
Pour les faits techniques, les avis publiés sur php.net ; pour l'évaluation de la situation en Allemagne, le BSI. Les articles de presse et les blogs d'éditeurs complètent le tableau, mais doivent être présentés comme des rapports et lus en regard de la source primaire.
Toutes les versions de PHP à partir de PHP 5 sont-elles vraiment concernées ?
La situation est établie pour les branches 8.2 à 8.5, pour lesquelles des mises à jour existent. Selon la presse spécialisée, presque toutes les versions jusqu'à PHP 5.4 sont concernées ; CERT-EU jugeait possible, selon des rapports, que les versions à partir de PHP 5 le soient. Il n'existe aucune mise à jour officielle pour les versions plus anciennes ; vous devez donc de toute façon les considérer comme exposées.