PHP2Shell : ce que tout développeur PHP doit faire cette semaine

Dans mon dernier article, je défendais PHP chiffres à l’appui : il fait tourner près de 70 % des sites web dont le langage serveur est connu. Cette semaine rappelle l’autre face de ce succès : un langage aussi répandu est une cible de choix.

Le 21 octobre 2026, PHP a publié en urgence des correctifs pour deux failles critiques, surnommées PHP2Shell. Si vous avez un site ou une API en PHP en production, cet article est pour vous.

Ce qui se passe

Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Elles ont chacune un score de gravité de 9,2 sur 10.

Elles permettent une exécution de code à distance : un attaquant peut prendre le contrôle du serveur. Le plus inquiétant :

• Une seule requête suffit, sans être connecté.

• L’attaque se produit avant même que votre code ne s’exécute. Un code Laravel parfaitement écrit ne vous protège pas.

• Elles sont déjà exploitées. Amazon a enregistré une tentative le 17 octobre, quatre jours avant l’annonce publique.

Qui est concerné ?

Pratiquement toute installation PHP qui répond à des requêtes web : PHP-FPM (le cas classique avec Nginx), Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Les configurations par défaut sont vulnérables.

Les versions corrigées sont :

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

Les branches 7.4, 8.0 et 8.1 sont aussi touchées, mais elles ne sont plus officiellement supportées. Si vous êtes encore dessus, c’est le moment de migrer.

Étape 1 : vérifier la bonne version

Attention à un piège courant : la version de PHP en ligne de commande n’est pas forcément celle qui sert votre site. Vérifiez les deux :

bash

# PHP en ligne de commande
php -v

# PHP-FPM (adaptez le numéro de version)
php-fpm8.3 -v

Le plus fiable reste de vérifier depuis le serveur web lui-même, par exemple avec une page phpinfo() temporaire, à supprimer juste après.

Autre piège : les distributions Linux comme Debian corrigent souvent les failles sans changer le numéro de version. Consultez l’avis de sécurité de votre distribution, pas seulement le numéro affiché.

Pensez aussi à vos conteneurs Docker : chaque image embarque son propre PHP.

Étape 2 : mettre à jour

C’est la seule protection complète. Sur Debian ou Ubuntu :

bash

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm

Le redémarrage de PHP-FPM est indispensable : sans lui, les anciens processus continuent de tourner avec le code vulnérable.

Pour Docker, reconstruisez vos images à partir d’une image de base à jour, puis redéployez.

En attendant le correctif

Si vous ne pouvez pas mettre à jour immédiatement, quelques réglages réduisent le risque. Pour la seconde faille, désactivez dans php.ini :

ini

session.upload_progress.enabled = 0

Puis redémarrez tous les workers. Un pare-feu applicatif comme Cloudflare, qui a déployé des règles contre cette attaque, ajoute aussi une couche de protection.

Ce ne sont que des mesures temporaires. Le correctif reste indispensable.

Comment savoir si on a été visé

Surveillez dans vos journaux :

• Des erreurs « Allowed memory size … exhausted » avec la mention Unknown on line 0.

• Des plantages de workers (segmentation fault).

• Surtout, un processus PHP qui lance un shell (sh, bash) ou ouvre des connexions sortantes inhabituelles.

Une attaque réussie ne fait pas forcément planter le serveur et peut renvoyer une réponse normale. En cas de doute, examinez le serveur en profondeur.

PHP n’est pas mort, et cette faille ne change rien à ce constat. Mais un serveur en production n’est jamais « terminé ». Mettre à jour régulièrement fait partie du travail, au même titre qu’écrire du code.