En bref : PHP2Shell et Log4Shell ont en commun d'être des failles critiques dans une brique de base très répandue, par lesquelles des attaquants peuvent exécuter du code sans authentification. Elles diffèrent par la visibilité, le classement et la situation concernant les attaques connues. La principale leçon de Log4Shell vaut aujourd'hui sans changement : qui sait où tourne la brique concernée agit en heures plutôt qu'en semaines.
Pourquoi la comparaison apparaît partout en ce moment
En décembre 2021, Log4Shell a tenu le monde informatique en haleine pendant des semaines. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) avait alors déclaré le niveau d'alerte le plus élevé, le rouge. Presque cinq ans plus tard, le même nom revient dans de nombreux articles sur PHP2Shell, souvent accompagné de la question : « Cela va-t-il être aussi grave ? »
La comparaison est naturelle, et elle est utile si on la mène correctement. Elle montre quels schémas se répètent et quelles expériences les entreprises peuvent utiliser directement aujourd'hui. La manière dont le BSI classe la situation actuelle est expliquée dans l'article Niveau d'alerte orange du BSI.
PHP2Shell et Log4Shell en comparaison directe
| Caractéristique | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Logiciel concerné | bibliothèque Java Log4j | environnement d'exécution PHP lui-même |
| Identifiant | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Évaluation | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Effet | exécution de code sans authentification | exécution de code sans authentification |
| Niveau d'alerte du BSI | 4 / rouge | 3 / orange |
| Situation lors de l'alerte | compromissions connues selon les rapports de l'époque | tentatives d'attaque rapportées, selon le BSI aucune attaque réussie confirmée à grande échelle dans un premier temps |
| Visibilité | souvent enfouie profondément dans les applications | visible sur le serveur, mais niveau de correctif difficile à lire à cause des rétroportages |
| Avis de suite | plusieurs autres CVE en quelques semaines | avis sur CVE-2026-115560 le 23.10. |
Ce que les deux failles ont en commun
Une brique de base, d'innombrables applications. Log4j se trouvait dans des logiciels Java de tout genre, PHP porte WordPress, Shopware, TYPO3 et d'innombrables développements maison. Dans les deux cas, ce n'est pas un produit qui est touché, mais un socle.
Aucune connexion nécessaire. Les deux failles permettent l'exécution de code à distance sans authentification. Cela les rend attrayantes pour les attaques automatisées.
Le correctif n'est pas la fin. Avec Log4Shell, il est apparu que de nombreux systèmes avaient déjà été attaqués avant la mise à jour. Avec PHP2Shell aussi : un correctif ne supprime pas un logiciel malveillant introduit. Selon des articles de presse, une première tentative d'attaque a déjà été observée le 17 octobre.
Avis de suite. Après Log4Shell, d'autres CVE sur Log4j sont parues en quelques semaines. Pour PHP, l'avis sur CVE-2026-115560 est venu deux jours après les correctifs. Pourquoi d'autres avis sont probables, l'article Après PHP2Shell : pourquoi d'autres avis sont probables l'explique.
Où la comparaison boite
La plus grande différence tient à la visibilité. Log4j était souvent intégrée comme partie d'une application, parfois imbriquée plusieurs fois. De nombreux exploitants ne savaient tout simplement pas qu'ils l'utilisaient. PHP, en revanche, n'est pas un secret sur un serveur web. En contrepartie, PHP2Shell crée une autre incertitude : les distributions et hébergeurs appliquent des corrections sous forme de rétroportage, le numéro de version affiché reste le même. On voit PHP, mais pas immédiatement s'il est corrigé.
Une deuxième différence est la situation de départ pour la mise à jour. Avec Log4Shell, les éditeurs d'applications métier devaient souvent d'abord livrer de nouvelles versions. Avec PHP2Shell, des mises à jour sont disponibles pour toutes les branches prises en charge. Cela devient difficile avec PHP 8.1 et plus ancien, pour lesquels le projet PHP ne publie plus de mises à jour officielles.
Une troisième différence concerne le lieu de l'attaque. Avec Log4Shell, tout endroit où une application journalisait des entrées pouvait être dangereux, donc aussi des systèmes internes qui ne recevaient que indirectement des données d'Internet. Avec PHP2Shell, le serveur web qui reçoit directement les requêtes est au centre. Cela rend la recherche des systèmes concernés un peu plus lisible : d'abord tous les services PHP accessibles publiquement, ensuite les applications internes.
Enfin, la situation diffère quant à l'exploitation. Pour Log4Shell, des outils d'attaque simples ont circulé tôt, et des compromissions étaient connues, selon les rapports de l'époque, dès le moment de l'alerte. Pour PHP2Shell, Cloudflare et Patchstack font état de tentatives d'attaque, watchTowr a reproduit l'une des failles selon ses propres indications, le BSI n'a pas signalé dans un premier temps d'attaques réussies confirmées à grande échelle. Cela peut changer. C'est toutefois une raison pour laquelle la comparaison ne vaut pas pronostic.
Utilisez les expériences de Log4Shell dans votre propre maison : quelles listes, procédures et contacts ont aidé à l'époque ? Beaucoup peut être réutilisé directement pour PHP2Shell.
Cinq leçons de Log4Shell qui aident aujourd'hui
- L'inventaire avant le correctif : qui disposait en 2021 d'une liste à jour de ses systèmes a été plus rapide. Cela vaut tout autant aujourd'hui. L'article Inventaire de tous les sites web et serveurs propose une marche à suivre.
- Connaître les dépendances : une nomenclature des briques logicielles, SBOM en abrégé, répond en quelques minutes à la question « Où utilisons-nous cela ? ». Pour les applications PHP, un regard dans Composer aide, comme le décrit Vérifier les dépendances Composer.
- Conserver les journaux : après Log4Shell, de nombreuses entreprises n'ont plus pu déterminer si elles étaient concernées, faute de journaux. La presse spécialisée conseille pour PHP2Shell de sauvegarder les journaux à partir du 20 octobre.
- Vérifier après coup : un correctif ne répond pas à ce qui s'est passé auparavant. Une recherche de traces en fait partie.
- Être prêt pour les avis de suite : la première mise à jour est rarement la dernière. Qui a une fois mis en place proprement la méthode de mise à jour la répète rapidement.
Comment PHP SOS aide-t-il concrètement ?
- Inventaire : nous déterminons où PHP tourne dans votre entreprise, dans quelle version et quel mode d'exécution.
- Correctif et redémarrage : nous installons les mises à jour et prouvons l'état de chaque système.
- Recherche de traces : nous sauvegardons les journaux et recherchons des anomalies depuis le 17 octobre.
- Suivi durable : nous gardons vos systèmes à l'œil afin que les avis de suite ne repartent pas de zéro.
À quoi ressemble la surveillance continue, Surveillance de sécurité pour serveurs web le décrit.
Conclusion
PHP2Shell n'est pas Log4Shell, mais l'histoire rime. Les deux touchent un socle, les deux demandent plus qu'un correctif. Les entreprises qui ont retenu de 2021 l'inventaire, la conservation des journaux et les méthodes de mise à jour sont aujourd'hui avantagées. Pour toutes les autres, c'est maintenant le moment de rattraper cela.
Questions fréquentes
PHP2Shell est-elle aussi grave que Log4Shell ?
Les deux sont des failles critiques dans un logiciel très répandu, par lesquelles des attaquants peuvent exécuter du code sans authentification. Le BSI a classé Log4Shell en 2021 au rouge, PHP2Shell à l'orange. Une différence importante : pour Log4Shell, selon les rapports de l'époque, des compromissions étaient déjà connues au moment de l'alerte ; pour PHP2Shell, selon le BSI, aucune attaque réussie confirmée à grande échelle dans un premier temps.
Qu'était Log4Shell ?
Log4Shell était une faille critique dans la bibliothèque Java Log4j, devenue publique en décembre 2021 et référencée sous CVE-2021-44228. Log4j était intégrée comme brique dans de très nombreuses applications, souvent sans que les exploitants le sachent.
D'autres failles vont-elles suivre PHP2Shell ?
C'est possible. Après Log4Shell, d'autres CVE sur Log4j ont suivi en quelques semaines. Pour PHP, un avis sur CVE-2026-115560, qui ne s'applique qu'avec une configuration inhabituelle, a déjà paru le 23 octobre. Prévoyez des avis de suite.
Qu'est-ce qu'une SBOM ?
Une Software Bill of Materials est une nomenclature de tous les composants logiciels dont se compose une application. Elle permet, face à une nouvelle faille, de déterminer rapidement où le composant concerné est utilisé.