Tentative ou intrusion réussie ?
Une requête multipart étrange ou une alerte WAF peut signaler une tentative. OOM, SIGSEGV/SIGABRT et pics HTTP 500 ont aussi des causes ordinaires. Processus enfants PHP, connexions, fichiers ou comptes inattendus exigent enquête. Une fuite mémoire peut ne laisser ni webshell ni fichier ; un scan propre ne l’exclut pas.
Croiser plusieurs journaux
Conservez fuseaux et décalages d’horloge. Reliez identifiants et heures du proxy aux erreurs PHP/FPM, PID, événements WAF, processus et réseau. Examinez le PHPSESSID de Set-Cookie dans la RÉPONSE, pas seulement les cookies entrants. Longueur ou encodage pour cent sont des pistes ; les motifs locaux ne prouvent pas PHP2Shell.
Aucune correspondance ne signifie pas absence d’intrusion
Les journaux d’accès omettent souvent corps, en-têtes de réponse et sessions. Sans déchiffrement autorisé, le capteur ne voit pas le HTTP chiffré. Rétention, réplicas oubliés et activité mémoire créent des angles morts. Documentez hôtes et périodes, demandez les journaux de l’hébergeur et escaladez les risques. Corriger ne reconstitue pas le passé.
journalctl -u php8.3-fpm --since "2026-10-21 00:00:00 UTC" --until "2026-10-22 23:59:59 UTC" --no-pager
journalctl -k --since "2026-10-21 00:00:00 UTC" --no-pager
ps -eo pid,ppid,lstart,args
ss -tpn
# Only use an independently trusted pre-incident manifest:
sha256sum -c /path/to/trusted-manifest.sha256Sources primaires et lectures complémentaires
PHP security teamLire l’original ↗CVE-2026-109618Lire l’original ↗CVE-2026-109619Lire l’original ↗php2shell.ukLire l’original ↗Analyses et guides pratiques
Outils PHP2Shell
Vérifiez un site public, examinez des paramètres et journaux locaux ou trouvez des outils ouverts. Chaque résultat expose ses preuves et limites.
01Comprendre PHP2Shell simplement
PHP est le moteur de WordPress, Laravel et des plugins. Mettre à jour un plugin ne met pas PHP à jour. Deux failles mémoire peuvent transformer un nettoyage anormal de requête en divulgation ou exécution de code. Le contrôle public fournit des indices ; l’hébergeur doit confirmer le runtime Web et son correctif.
02Tentative ou intrusion réussie ?
Une requête multipart étrange ou une alerte WAF peut signaler une tentative. OOM, SIGSEGV/SIGABRT et pics HTTP 500 ont aussi des causes ordinaires. Processus enfants PHP, connexions, fichiers ou comptes inattendus exigent enquête. Une fuite mémoire peut ne laisser ni webshell ni fichier ; un scan propre ne l’exclut pas.
03Préserver avant de modifier
Notez heure de découverte, domaine, instance, runtime, symptômes et dernier état fiable. Exportez journaux originaux et fuseaux, audits cloud et instantanés autorisés disponibles. Restreignez les copies et calculez leurs empreintes. N’envoyez pas de cookies, jetons ou données clients aux scanners publics. Ne videz pas les journaux et ne supprimez pas les fichiers suspects avant préservation.
04Lire Wiz et Calif avec précision
Les recherches décrivent des erreurs survivant aux requêtes. L’avis CVE-2026-109618 démontre une RCE mod_php ; l’exposition FPM repose sur le code, sans exploit FPM complet pour ce CVE. CVE-2026-109619 confirme séparément un chemin FPM lié à l’application et au suivi des téléversements. Vérifiez les preuves de chaque SAPI dans son GHSA.
05Cloudflare : examiner aussi la réponse
Cloudflare décrit une détection combinant requête et réponse d’origine, pouvant bloquer une réponse suspecte avant divulgation. Utile même sans lancement de shell. Le calendrier historique ne garantit pas votre couverture : vérifiez règles, routage, exclusions et événements. Les accès directs à l’origine et hôtes hors proxy doivent aussi être corrigés.