Cloudflare : 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.
CloudflareLire l’original ↗Akamai, Imperva et Unit 42
Akamai cite Adaptive Security Engine 3000991 v1 ; Unit 42, Threat ID 543004 et inventaire ; Imperva, protection multicouche. Ce sont des fonctions de produits, pas des règles WAF universelles. Vérifiez avis actuels, politique active et chemin réel du trafic. Une requête bloquée ne démontre pas l’échec des tentatives antérieures.
AkamaiLire l’original ↗ImpervaLire l’original ↗Palo Alto Networks Unit 42Lire l’original ↗Corelight et Cisco Talos
Corelight publie des règles Zeek/Suricata. Potentially_Affected_PHP_Version est un indice d’inventaire distinct des corrélations de requêtes/sessions. Il faut voir le HTTP ; certains seuils restent provisoires. Vérifiez les avis actuels. Talos cite Snort 67359, 67360, 67375. Absence d’alertes ou en-têtes cachés ne prouve pas la sécurité.
CorelightLire l’original ↗Cisco TalosLire l’original ↗Ce que montre l’endpoint
CrowdStrike décrit une protection contre des activités ultérieures à l’exploitation. Corrélez processus enfants PHP, shells, connexions et persistance avec les requêtes Web. Ces preuves renforcent l’enquête ; l’absence de shell n’exclut pas une fuite mémoire. Reliez les affirmations au produit et à la date, puis croisez réseau et hôte.
CrowdStrikeLire l’original ↗Sources primaires et lectures complémentaires
PHP security teamLire l’original ↗CVE-2026-109618Lire l’original ↗CVE-2026-109619Lire 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.