PHP2Shell : comment savoir si votre site PHP a été attaqué

1. Où en est l'exploitation

Amazon a relevé une tentative dès le 17 octobre. Après la publication du 21, Cloudflare dit être passé de dizaines de milliers de tentatives en 45 minutes à des millions le lendemain matin, et voir les attaquants adapter leurs requêtes pour contourner ses règles. Sophos et Arctic Wolf décrivent des essais d'installation d'une variante du botnet Mirai. Wordfence et d'autres rapportent surtout du scan et des sondages. Selon The Hacker News, les chercheurs jugent un exploit fiable plus difficile à construire qu'annoncé.

Ce dernier point ne doit pas rassurer. Datadog a produit un exploit fonctionnel contre mod_php, avec une simple requête sans authentification, et la CISA a inscrit la faille à son catalogue des vulnérabilités exploitées. La capacité existe, les attaquants testent, et ils s'améliorent.

2. Ce que laisse une attaque

Une attaque réussie ne fait pas forcément planter le serveur. Datadog note que la requête peut répondre normalement, avec un code 200. Trois familles de signaux existent.

Une limite à connaître : le journal d'accès par défaut de nginx n'enregistre ni le corps des requêtes ni leur type de contenu. Vous ne verrez donc pas les champs d'envoi de fichiers. Vous verrez les requêtes POST, leur cible, et les erreurs 500 ou 502 qui les accompagnent.

3. Les commandes à lancer

Les chemins ci-dessous correspondent à Debian 12, nginx et PHP 8.2. Adaptez le numéro de version et le dossier du site. Toutes ces commandes lisent sans rien modifier.

Le journal d'erreurs de PHP-FPM

sudo zgrep -hE "Unknown on line 0|Allowed memory size|exited on signal|SIGSEGV" /var/log/php8.2-fpm.log*

Un résultat vide est bon signe. Quelques lignes datées du 17 au 21 octobre, surtout avec « Unknown on line 0 », méritent d'être regardées de près.

Les erreurs 500 et 502, jour par jour

sudo zcat -f /var/log/nginx/access.log* | awk '$9 ~ /^(500|502)$/ {print substr($4,2,11)}' | sort | uniq -c

Un pic inhabituel sur un jour, sans lien avec une mise à jour ou une panne connue, est un indice de plus.

Les cibles des requêtes POST

sudo zcat -f /var/log/nginx/access.log* | grep '"POST ' | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Sur un WordPress, vous attendez surtout wp-login.php (ou votre adresse personnalisée), admin-ajax.php et wp-cron.php. Un POST sur la racine ou sur un fichier que vous ne reconnaissez pas est à noter.

Les processus et les connexions

sudo ps -u www-data -o pid,ppid,etime,cmd --forest
sudo ss -tnp | grep -E "php-fpm|www-data"

Les processus attendus sont php-fpm et les workers nginx. Un sh, un bash, un curl, un wget, un python ou un processus inconnu sous www-data justifie une enquête immédiate. Les connexions normales de PHP-FPM vont vers la base de données et vers les services dont dépend votre site ; une connexion vers une adresse inconnue sur un port inhabituel ne l'est pas.

Les fichiers récents

sudo find /var/www/html -name "*.php" -newermt "2026-10-17" -not -path "*/wp-content/plugins/*" -not -path "*/wp-content/cache/*" -ls
sudo find /var/www/html -path "*/uploads/*" -name "*.php" -ls
sudo find /tmp /var/tmp /dev/shm -user www-data -newermt "2026-10-17" -ls
sudo crontab -u www-data -l

Aucun fichier PHP ne devrait traîner dans le dossier des téléversements. Un fichier récent hors plugins, dans le cœur de WordPress ou dans un dossier temporaire, est suspect. Une mise à jour de WordPress ou d'un thème peut en créer légitimement : comparez avec vos dates de mise à jour. « no crontab for www-data » est la réponse normale.

WordPress lui-même

sudo -u www-data wp core verify-checksums --path=/var/www/html/wordpress
sudo -u www-data wp plugin verify-checksums --all --path=/var/www/html/wordpress
sudo -u www-data wp user list --role=administrator --fields=ID,user_login,user_registered --path=/var/www/html/wordpress

Ces commandes demandent WP-CLI. Les deux premières comparent vos fichiers aux versions officielles, la troisième liste les administrateurs : tout compte que vous ne reconnaissez pas est un signal fort.

4. Si vous trouvez quelque chose

Un seul indice isolé ne prouve pas une intrusion, et un résultat vide ne prouve pas le contraire. Si plusieurs signaux concordent, par exemple une erreur « Unknown on line 0 » suivie d'un fichier PHP inconnu, traitez-le comme un incident.

5. Réduire le risque pour la suite

Gardez PHP à jour, et gardez session.upload_progress.enabled=0 : le projet PHP le recommande aussi contre une troisième faille signalée le 23 octobre, CVE-2026-115560, qui n'a pas encore de correctif ni d'exploitation connue. Si vous n'utilisez pas l'envoi de fichiers, refusez les requêtes multipart en amont, au niveau de nginx ou du pare-feu applicatif. Cloudflare a activé des règles par défaut, ce qui aide sans remplacer la mise à jour.

Envoyez aussi vos journaux hors du serveur. Un attaquant qui exécute des commandes peut effacer les traces locales. Et planifiez la migration hors de PHP 8.2, qui sort du support le 31 décembre 2026.

6. Conformité

Une intrusion qui touche des données personnelles est une violation au sens du RGPD : notification à la CNIL sous 72 heures si le risque pour les personnes est avéré, et inscription au registre des violations dans tous les cas. Pour les entités soumises à NIS2, un incident significatif suppose une alerte précoce sous 24 heures. Dans les deux cas, les journaux que vous aurez copiés vous serviront de preuve.

7. Ce que 2LKATIME recommande

Si vous ne savez pas lire ces résultats, ou si l'un d'eux vous inquiète, ne tardez pas : la fenêtre de journaux s'étrécit chaque jour. Nos audits cybersécurité incluent une analyse de compromission et une revue de configuration du serveur.

Les structures de Paris, de Lyon ou de Bordeaux trouveront les formules sur nos pages tarifs. L'analyse se fait aussi à distance partout en France.

FAQ - Détecter une attaque PHP2Shell