PHP2Shell : Unit 42 retire son lien, le scan continue

Ce qui change

Unit 42 (Palo Alto Networks) avait attribué à PHP2Shell une attaque contre une agence gouvernementale européenne : en deux heures, des empreintes de mots de passe et des secrets d'authentification multifacteur, puis un tunnel de relais NTLM vers Active Directory. Les commandes, encadrées de séparateurs comme ==SHELLUSER== et ==PASSWD==, évoquaient un agent d'IA.

Mise à jour du 25 octobre : Unit 42 retire ce rattachement. Ses chercheurs ont vu une attaque « dans le contexte d'une application PHP vulnérable » et ne peuvent pas confirmer que l'accès initial vienne des deux failles, CVE-2026-109618 et CVE-2026-109619. L'attaque assistée par IA attribuée à PHP2Shell n'est donc plus établie.

Ce qui continue

• CYFIRMA décrit une campagne soupçonnée d'être nord-coréenne (confiance modérée, écosystème Lazarus) : 21 nœuds compromis sondent 216 hôtes non corrigés ou partiellement protégés, aux États-Unis, au Japon, en Corée du Sud, en Thaïlande, en Indonésie, en Australie, à Taïwan, en Inde, à Singapour, dans les Émirats, en Arabie saoudite et dans l'UE. Le débit est volontairement faible et un nœud est abandonné au premier blocage : une alerte à seuil ne la verra pas. Selon CYFIRMA, l'exploitation est « l'étape suivante ».
• Defused Cyber voit, le 25 octobre, des sondes sur ses pièges GlobalProtect depuis 204.76.203.7, adresse connue de scan de masse. Les requêtes portent le marqueur PHP_SESSION_UPLOAD_PROGRESS valant p2s-rider et un faux envoi de fichier sans contenu : probablement une liste de cibles.
• Bitsight compte près de 37 millions de systèmes exposés sous PHP, surtout aux États-Unis, en Allemagne, en France, aux Pays-Bas et au Japon. Cloudflare a rapporté des millions de tentatives après la divulgation.

Que chercher dans les journaux

ReliaQuest a reproduit CVE-2026-109618 en laboratoire (22 octobre). La séquence à retrouver, dans cet ordre :

1. une requête POST qui répond 500 ;
2. PHP qui signale un épuisement mémoire et une corruption de tas ;
3. le worker Apache qui traitait la requête qui plante.

Datadog précise le principe : un nom de champ assez court pour passer la limite du corps de requête, assez long pour que sa copie dépasse memory_limit, ce qui fait échouer une allocation au bon moment.

Comment s'y prendre

1. Installer PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou le paquet corrigé de la distribution), puis redémarrer chaque worker et vérifier la version réellement chargée.
2. Remonter dans les journaux jusqu'au 17 octobre, date de la première tentative connue (voir la fiche du 23 octobre).
3. Chercher p2s-rider, la séquence ci-dessus et l'adresse 204.76.203.7, sans s'y limiter : CYFIRMA note que les nœuds tournent.
4. Pour CVE-2026-115560, troisième exécution de code, rester sur session.upload_progress.enabled=0 (fiche du 24 octobre).

Un pare-feu applicatif ne remplace pas la mise à jour : Bitsight rappelle que la faille est dans le runtime et que seule la mise à jour de PHP sur l'hôte la ferme. Xint publie un scanner, phpguard.io, pour tester un hôte.

Source : The Hacker News, 25 octobre 2026. Source en anglais. Unit 42 : rapport ; CYFIRMA : avis.