Contexte et tendances d'exposition

Après la divulgation publique du problème PHP2Shell le 21 octobre 2026, la télémétrie de Wiz indique une baisse d’environ 67 % du nombre quotidien de machines exposées sur Internet et vulnérables. Sur la même période, la part des serveurs exécutant PHP 7.3 ou antérieur est passée de 8,3 % à 5,7 %, soit une réduction de 2,6 points en cinq jours. Le nombre d’organisations contenant au moins une instance exposée a chuté de 47,9 %. Pour mettre ces chiffres en perspective, PHP est présent dans 65 % des organisations du jeu de données de Wiz.

Ces évolutions suggèrent que les acteurs ont combiné plusieurs stratégies de remédiation : correctifs appliqués, mise à jour vers des versions récentes, mise hors service de serveurs anciens et restriction de l’accès Internet. La méthodologie de collecte (balayage, taille de la population observée) n’est pas détaillée, ce qui empêche d’isoler l’impact de chaque mesure.

Analyse des tentatives d’exploitation

Wiz a identifié deux variantes d’outils open‑source exploitant le mécanisme PHP2Shell. Aucun des flux capturés n’a abouti à une compromission complète.

Variante 1 : chaîne legacy. Le premier paquet, envoyé depuis l’adresse 3.37.227[.]134, contenait un corps multipart de 1 005 parties dont un champ big d’environ 12 Mo. Le serveur a rejeté la requête avec le message : « POST Content‑Length of 12655437 bytes exceeds the limit of 8388608 bytes », démontrant que la configuration post_max_size (8 Mo) a empêché le dépassement de mémoire prévu.

POST / HTTP/1.1
Host: 
Content-Type: multipart/form-data; boundary=SSSSSSSSSSSSSSSSS
Content-Length: 12655437
[1,005 parts]
... big = "B" (≈12 Mo)

Une seconde tentative contre Roundcube a envoyé 1 001 champs de 3 000 octets chacun, mais n’a pas déclenché le flux d’épuisement de mémoire attendu.

Variante 2 : chaîne actuelle. Cette version, basée sur pure/mk_a1.py et pure/mk_leak_b.py, a réussi à faire atteindre la limite de mémoire PHP (Allowed memory size of 134217728 bytes exhausted) mais a échoué à extraire les adresses mémoire nécessaires pour poursuivre l’exploitation.

Le succès partiel repose sur le maintien de la connexion sur le même processus enfant d’Apache. Pour augmenter les chances, le kit ouvre de nombreuses connexions incomplètes, chacune déclarant un corps de 1 MiB puis n’envoyant qu’un octet avant de rester en attente :

POST /index.php HTTP/1.1
Host: 
Content-Type: application/x-www-form-urlencoded
Content-Length: 1048576
x

L’adresse 178.249.214[.]6 a ouvert 399 de ces connexions simultanément, illustrant la tactique de saturation des workers Apache.

Implications et limites

Les deux variantes montrent que l’exploitation repose sur deux conditions critiques : le dépassement de la mémoire PHP et la persistance de la session sur le même worker. Les configurations standards (post_max_size, memory_limit) bloquent déjà la première condition, tandis que la deuxième dépend de la politique de gestion des workers du serveur web, souvent aléatoire.

À ce jour, aucun PoC public ne démontre une chaîne d’exploitation complète contre une cible arbitraire. Des partenaires ont toutefois fourni des exploits privés, mais leur portée reste non vérifiée publiquement. L’absence de preuve de concept généralisée limite la capacité des défenseurs à valider leurs défenses au moyen de tests d’intrusion réalistes.

En résumé, la diminution rapide de l’exposition observée reflète l’efficacité des correctifs et des bonnes pratiques de configuration. Cependant, la persistance de tentatives sophistiquées, même incomplètes, justifie la surveillance continue des paramètres PHP et la mise en place de limites strictes sur la taille des requêtes et la gestion des workers Apache.