Comparaison

PHP2Shell vs Log4Shell

Dans les deux cas, il s’agit d’exécution de code à distance sans authentification dans un logiciel présent sous une énorme part d’Internet. Les grandes différences : Log4Shell était trivial à exploiter et difficile à repérer ; PHP2Shell est plus difficile à exploiter et plus facile à repérer.

Dernière vérification 2026-10-22

PHP2ShellLog4Shell
De quoi s’agit-ilDeux bugs de sécurité mémoire dans l’interpréteur PHPInjection de recherche JNDI dans la bibliothèque de journalisation Java Log4j 2
CVECVE-2026-109618, CVE-2026-109619CVE-2021-44228 (plus des CVE de suivi)
Divulgation21 oct. 2026 (fuite le 20 oct.)9 déc. 2021 (exploit public le jour même)
ScoreCVSS 4.0 9.2CVSS 3.1 10.0
AuthentificationAucuneAucune
Difficulté d’exploitationPlus élevée : requêtes multipart forgées, ajustées à la disposition mémoire de chaque cible au fil de tentatives répétéesTriviale : une chaîne comme ${jndi:ldap://…} partout où elle est journalisée
PortéeTout site sur un PHP vulnérable — une grande partie du webToute application Java journalisant des entrées d’attaquant avec Log4j 2.0–2.14.1 — serveurs, appliances, jeux
Repérer les systèmes concernésPlutôt simple : c’est l’environnement PHP ; vérifiez la version par serveur ou conteneurDifficile : Log4j se cachait en dépendance transitive dans des JAR et des produits d’éditeurs
CorrectionMettre PHP à jour et redémarrer les workersMettre à jour Log4j (plusieurs vagues : 2.15 → 2.16 → 2.17) et reconstruire chaque application concernée
Qui corrigeCelui qui gère le serveur : vous, votre hébergeur ou votre fournisseur cloudChaque éditeur ayant embarqué Log4j, plus tous ceux qui font tourner ces applications
AttaquesPremières attaques signalées le jour de la publication ; aucune compromission confirmée publiée à ce stadeExploitation de masse en quelques heures ; inscrite au KEV de la CISA
Vol de données sans RCEOui — chemin de divulgation mémoireIndirectement (variables d’environnement via des requêtes DNS)

Ce qui les rapproche

  • Pas de connexion, pas d’interaction utilisateur — seulement des requêtes réseau.
  • Un logiciel de base auquel la plupart des propriétaires ne pensent jamais : beaucoup de systèmes resteront longtemps non corrigés.
  • Les mises à jour applicatives n’aident pas ; la couche vulnérable est en dessous.

Ce qui les distingue

  • Effort d’exploitation. Log4Shell tenait en une chaîne à copier-coller ; PHP2Shell est une chaîne de corruption mémoire à adapter à chaque cible. Attendez-vous d’abord à des attaquants moins nombreux mais plus compétents — puis à des abus plus larges dès que des outils fiables circuleront.
  • Inventaire. « Quels serveurs font tourner PHP, et dans quelle version ? » se règle en quelques heures. Retrouver Log4j a pris des semaines aux organisations.
  • Longue traîne. La longue traîne de PHP, ce sont l’hébergement mutualisé et les serveurs abandonnés sur PHP 7.x et 8.0/8.1, qui ne reçoivent pas de nouvelle version.

Questions

PHP2Shell est-il aussi grave que Log4Shell ?+

Portée comparable et même pire scénario (exécution de code à distance sans authentification), mais plus difficile à exploiter : Log4Shell fonctionnait avec une seule chaîne dans n’importe quel champ journalisé, alors que les exploits PHP2Shell doivent être ajustés à chaque cible. PHP2Shell est plus facile à inventorier et à corriger, car il se trouve dans l’environnement PHP et non caché dans les dépendances applicatives.

Les correctifs ou scanners Log4j aident-ils contre PHP2Shell ?+

Non. Les deux n’ont rien à voir : Log4Shell est dans une bibliothèque de journalisation Java, PHP2Shell dans l’interpréteur PHP. Scanners différents, corrections différentes.

Voir aussi