En bref : un contournement de la faille de sécurité PHP2Shell peut réduire le risque, mais ne remplace pas la mise à jour. php.net cite pour cela des limites fixes de mémoire et d'envoi, la désactivation de Session Upload Progress et, sur PHP 8.5, fatal_error_backtraces=0. Si même cela n'est pas possible à court terme, le BSI recommande de déconnecter temporairement le serveur web du réseau.
Ce qu'un contournement peut apporter et ce qu'il ne peut pas
Les mesures transitoires de php.net doivent compliquer les conditions dans lesquelles les failles CVE-2026-109618 et CVE-2026-109619 sont exploitables. Elles ne sont expressément pas une protection complète. Les failles ne sont corrigées que dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou dans un backport confirmé par votre fournisseur.
Les mesures sont judicieuses lorsque la mise à jour n'est pas encore possible pour une raison concrète : une fenêtre de maintenance est encore à venir, une application doit d'abord être testée, ou vous exploitez PHP 8.1 ou antérieur, pour lequel il n'existe plus de mise à jour officielle. Elles sont alors un pont, pas un but.
Planifiez donc la mise à jour en même temps que le contournement : qui la réalise, dans quelle fenêtre de maintenance, et qui vérifie ensuite que tous les workers ont été redémarrés ? Une transition sans date de fin risque de devenir un état permanent.
Option 1 : déconnecter temporairement le serveur du réseau
Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) a émis le niveau d'alerte 3 (orange) et recommande de déconnecter temporairement du réseau les serveurs web concernés lorsque la mise à jour n'est pas possible immédiatement. Certains fournisseurs l'ont fait par précaution ; cela ne signifie pas que ces sites ont été piratés.
Pour de nombreuses entreprises, une panne de la boutique ou du portail coûte cher. Une pesée peut être judicieuse : accès uniquement via VPN ou adresses IP autorisées, une page de maintenance statique à la place de l'application PHP, ou l'arrêt de certains sites web inutiles sur le serveur. Moins PHP est accessible depuis l'extérieur, plus la surface d'attaque est petite.
Il importe de prendre la décision consciemment et de la consigner : qui a décidé, quand, de laisser le serveur en ligne, et avec quelles mesures de protection ? Cela aide plus tard face à l'assureur, à la protection des données et à la direction.
Les mesures transitoires de php.net
| Mesure | Valeur | Remarque |
|---|---|---|
memory_limit |
-1, non écrasable |
définir alors la limite de mémoire via conteneur ou cgroup |
post_max_size |
8M sans envois de fichiers, 32M avec |
upload_max_filesize en dessous |
| Limite de mémoire | via conteneur/cgroup | pas via RLIMIT_AS ou RLIMIT_DATA |
session.upload_progress.enabled |
0 |
dans php.ini, le pool ou la configuration du serveur, pas via ini_set() ni .user.ini |
fatal_error_backtraces |
0 |
PHP 8.5 uniquement |
Le réglage session.upload_progress.enabled=0 est en même temps la parade à la faille signalée le 23 octobre, CVE-2026-115560.
Appliquer correctement le contournement de la faille PHP
L'endroit est décisif. Les valeurs doivent être définies de telle sorte qu'une application ne puisse pas les écraser. Les chemins et noms de services varient selon la distribution ; les exemples partent de PHP 8.3.
PHP-FPM, dans le pool (p. ex. /etc/php/8.3/fpm/pool.d/www.conf) :
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 uniquement :
; php_admin_flag[fatal_error_backtraces] = off
Apache avec mod_php, dans la configuration du serveur ou de l'hôte virtuel :
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Limite de mémoire via cgroup, ici avec systemd pour le service FPM. Vous adaptez la valeur à votre serveur :
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Redémarrez ensuite tous les workers, sinon rien de tout cela ne s'applique : systemctl restart php8.3-fpm ou, avec mod_php, Apache. Comment vérifier qu'aucun ancien processus ne tourne plus, c'est expliqué sous Redémarrer PHP-FPM et tous les workers. Le durcissement général de la configuration est décrit dans Configurer php.ini de façon sûre.
Testez les envois de fichiers et les formulaires volumineux après la bascule. Un post_max_size trop juste peut bloquer des commandes, des formulaires de candidature ou des envois de médias. C'est une raison de ne pas repousser longtemps la mise à jour.
Couches de protection supplémentaires
Un pare-feu d'applications web ou un correctif virtuel peut aider comme couche supplémentaire. Cloudflare a déployé des règles de protection, mais avertit lui-même que des règles fondées sur les seules données de la requête ne suffisent pas. Un WAF est donc un complément, pas un substitut. Plus d'informations sous WAF et correctif virtuel.
Sauvegardez en outre les journaux du serveur à partir du 20 octobre. Selon des reportages de médias, une première tentative d'attaque a déjà été observée le 17 octobre ; les journaux sont la base si vous devez plus tard établir si quelque chose s'est produit avant le correctif.
Comment PHP SOS aide-t-il concrètement ?
- Clarifier la situation : nous vérifions si une mise à jour est possible à court terme ou si une transition est nécessaire, et discutons avec vous de l'option de déconnecter certaines parties du réseau.
- Mettre en place les mesures : nous inscrivons les valeurs de php.net au bon endroit, définissons la limite cgroup et redémarrons tous les workers.
- Tester le fonctionnement : nous vérifions les formulaires, envois de fichiers et processus de commande après la bascule.
- Mener au correctif : via le service de correctifs PHP, nous planifions la mise à jour et retirons ensuite de façon contrôlée les valeurs transitoires là où elles gênent.
Questions fréquentes
Le contournement protège-t-il complètement contre PHP2Shell ?
Non. php.net qualifie expressément les mesures de transitoires et non de protection complète. Elles réduisent le risque jusqu'à l'installation de la mise à jour. Le BSI recommande de déconnecter temporairement du réseau les serveurs sans correctif.
Puis-je définir les réglages via .htaccess ou .user.ini ?
Pour session.upload_progress.enabled, php.net exclut expressément ini_set() et .user.ini. Pour memory_limit aussi, la valeur doit être définie de telle sorte que l'application ne puisse pas l'écraser. Cela réussit dans php.ini, dans le pool FPM avec php_admin_value ou dans la configuration du serveur Apache.
Un pare-feu d'applications web suffit-il comme contournement ?
Comme couche supplémentaire, il peut aider. Cloudflare a déployé des règles de protection, mais souligne lui-même que des règles fondées sur les seules données de la requête ne suffisent pas. Un WAF ne remplace ni la mise à jour ni les mesures transitoires sur le serveur.
Que faire si je n'ai qu'un hébergement mutualisé ?
php.ini et le redémarrage relèvent alors de l'hébergeur. Demandez précisément si la mise à jour a été installée ou les mesures transitoires mises en place, et si tous les processus PHP ont été redémarrés.