Détection et réponse
Parallèlement à l’application des correctifs, le SOC recommande une analyse rétroactive des systèmes exposés au moins à partir du 17 octobre 2026, lorsque la télémétrie existe. Corrélez les accès suspects avec l’exécution de processus, les modifications de fichiers, les connexions sortantes et les événements d’authentification. L’absence de télémétrie ou d’alertes ne prouve pas qu’aucune exploitation n’a eu lieu.
1. Télémétrie des processus / EDR
Déclenchez une alerte pour tout processus lancé par php-fpm, php-cgi, httpd ou apache2 qui démarre un shell ou des outils de téléchargement (sh, bash, dash, curl, wget, nc, python, perl). En fonctionnement normal, ce comportement est rare et doit être traité comme une compromission possible.
2. Journaux web et PHP
• Rafales de requêtes POST multipart/form-data provenant de la même source, en particulier avec un nombre inhabituel de parties ou d’en-têtes.
• Noms de champs profondément imbriqués ou requêtes contenant PHP_SESSION_UPLOAD_PROGRESS, y compris vers des points de terminaison qui ne devraient pas accepter de téléversements.
• Réponses HTTP 500 répétées, plantages ou redémarrages inattendus des workers PHP.
• Cookies PHPSESSID malformés ou anormalement longs et erreurs répétées (SIGSEGV, AH00052, zend_mm_heap corrupted, "Allowed memory size … in Unknown on line 0") dans les journaux PHP, Apache ou FPM.
3. Système de fichiers et persistance
• Fichiers PHP nouveaux ou modifiés dans les répertoires de téléversement, de cache ou accessibles depuis le web; vérifiez l’horodatage, le propriétaire et le contenu.
• Nouvelles tâches cron pour l’utilisateur du serveur web, clés SSH ou comptes ajoutés récemment; connexions sortantes inhabituelles initiées par les workers web.
4. Comment utiliser les indicateurs de compromission (IOC)
Considérez les IOC comme des points de départ pour la corrélation, et non comme des preuves à part entière: certaines adresses peuvent appartenir à une infrastructure d’anonymisation ou apparaître dans du trafic légitime. Une correspondance ne confirme pas une compromission et ne justifie pas un blocage automatique. Validez la source, la date et le contexte de chaque indicateur, en le confrontant à la télémétrie hôte/réseau.
Réponse à incident: en cas de signes crédibles de compromission
1. Isolez le système affecté et limitez l’accès réseau sans détruire les preuves.
2. Préservez les journaux et, si possible, une image disque ainsi que les artefacts mémoire/processus pertinents.
3. Renouvelez tous les identifiants accessibles au processus web: mots de passe de bases de données, clés d’API, jetons et secrets .env.
4. Poursuivez l’investigation à la recherche de persistance, d’exfiltration et de mouvements latéraux. La seule mise à jour de PHP ne supprime pas l’accès d’un attaquant si le système était déjà compromis.
5. Faites remonter l’incident à l’équipe SOC/IR et évaluez les obligations de notification applicables (RGPD, NIS2).
Pour PHP 8.1 et les versions antérieures, vérifiez si votre distributeur fournit des correctifs rétroportés documentés. S’il n’existe aucun correctif pris en charge, planifiez une migration. Reconstruisez les images de conteneur à partir d’images de base mises à jour et redéployez-les; la mise à jour de l’hôte ne met pas à jour PHP à l’intérieur du conteneur.
