Détection & réponse
Ai-je été touché ?
Aucune règle unique ne repère toutes les variantes, et le code vulnérable s’exécute sous votre application : ses journaux peuvent ne rien montrer. Servez-vous de ces signaux pour prioriser — pas pour innocenter un système.
Dernière vérification 2026-10-22
L’absence de signaux ne prouve pas la sécurité
Le chemin de divulgation mémoire peut voler des secrets sans jamais exécuter de code sur le serveur. Mettez à jour quoi que vous trouviez.
Signaux à examiner
| Signal | Pourquoi c’est important | Où regarder |
|---|---|---|
| Erreurs fatales de limite mémoire juste après des POST multipart | L’épuisement mémoire est un déclencheur. CVE-2026-109619 a aussi des chemins sans OOM ; l’absence de ces erreurs ne l’exclut pas. | Journal d’erreurs PHP / FPM + journal d’accès du serveur web |
| Rafales de HTTP 500 depuis un même client | Les exploits ont besoin de plusieurs tentatives pour s’adapter à la disposition mémoire de la cible. | Journal d’accès |
| Workers qui meurent sur SIGSEGV / SIGABRT, ou renouvellement anormal des workers | Les tentatives de use-after-free ratées font souvent planter le worker. | Journal FPM, journal d’erreurs Apache, dmesg / journal |
| PHPSESSID anormalement long ou encodé en pourcentage dans les réponses | Le chemin de divulgation encode en URL la mémoire du tas divulguée dans le cookie de session — même sur des sites qui n’appellent jamais session_start(). | Journaux du reverse proxy / CDN / WAF avec Set-Cookie (absent des journaux d’accès par défaut) |
| Nouveaux fichiers .php dans la racine web, processus enfants inattendus de l’utilisateur PHP | Comportement classique après intrusion : webshells, curl/wget, reverse shells lancés par www-data. | Système de fichiers, EDR, comptabilité des processus |
Un PHPSESSID normal est court et alphanumérique (32 caractères par défaut). Des centaines de caractères ou des séquences d’octets %xx ne sont pas normaux.
Fouiller vos journaux
Les chemins sont ceux de Debian/Ubuntu par défaut. Adaptez-les à votre système ; couvrez au moins la période depuis début octobre 2026.
# 1. Memory-limit fatals (PHP's exact message)
sudo grep -rh "Allowed memory size of" /var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ /var/log/nginx/ 2>/dev/null | tail -50
# 2. Workers killed by signals
sudo grep -rhE "exited on signal (6|11)|exit signal (Segmentation fault|Aborted)" \
/var/log/php*-fpm.log /var/log/apache2/ /var/log/httpd/ 2>/dev/null | tail -50
sudo journalctl --since "2026-10-01" | grep -E "php.*segfault" | tail
# 3. Clients producing many 500s on POST (combined log format)
sudo awk '$6=="\"POST" && $9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
| sort | uniq -c | sort -rn | head -20Après correction, la nouvelle limite mémoire stricte peut aussi arrêter brutalement des workers. Un arrêt isolé ne prouve pas une attaque — cherchez des grappes liées au même client ou au même motif de requête.
Rechercher des traces de post-exploitation
# PHP files changed in the web root since the bugs became known (adjust path/date)
sudo find /var/www -type f -name '*.php' -newermt '2026-08-01' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -100
# Processes the web user is running right now (shells and downloaders are red flags)
ps -u www-data -o pid,ppid,lstart,cmd | grep -vE 'php-fpm|apache2|httpd'
# Established connections owned by PHP / Apache — review every remote address
sudo ss -tpn state established | grep -E 'php|apache|httpd'Couverture WAF
Les règles gérées sont une solution d’attente pendant la mise à jour. Consultez les recommandations PHP2Shell de votre fournisseur. Cloudflare a publié ses identifiants de règles — voir la page Cloudflare.
Détections des éditeurs
Si vous utilisez l’un de ces produits, leurs articles décrivent les signatures et requêtes de chasse qu’ils ont publiées.
- AkamaiCritical RCE vulnerabilities in PHP core
- ImpervaPHP2Shell vulnerability updates
- CorelightPHP2Shell detection
- CrowdStrikeProtecting customers from PHP RCE zero-days
- Unit 42CVE-2026-109618 / CVE-2026-109619
- Cisco TalosTwo critical RCEs in PHP core
- watchTowrPHP RCE FAQ: CVE-2026-109618
- SansecPHP2Shell: critical PHP RCE
N’exécutez pas de scripts « PoC » trouvés sur GitHub sur vos serveurs
Traitez les dépôts d’exploits et de scanners comme non fiables. Leur disponibilité publique ne prouve ni leur efficacité ni leur sécurité. Préférez les vérifications des éditeurs et ne testez jamais de scripts inconnus en production.
Si vous trouvez quelque chose
- Préservez d’abord les preuves : copiez les journaux et faites si possible un instantané disque / mémoire avant de reconstruire.
- Corrigez ou isolez l’hôte. Reconstruire depuis une image saine vaut mieux que nettoyer sur place.
- Renouvelez tout ce que PHP pouvait voir en mémoire : mots de passe de base de données, clés d’API, secrets client OAuth, identifiants SMTP, clés applicatives (
APP_KEY, salts WordPress), clés privées TLS si PHP y avait accès. - Invalidez les sessions pour que les cookies volés ne fonctionnent plus, et faites se reconnecter les administrateurs.
- Évaluez la portée : à quoi d’autre ces identifiants donnent accès (comptes cloud, API internes, autres bases de données).