En bref : de nombreux conseils sur PHP2Shell qui circulent actuellement dans les forums et sur les réseaux sociaux ne protègent pas, voire nuisent : bloquer les requêtes avec cookie de session, masquer les messages d'erreur, définir des paramètres via .user.ini ou ne mettre à jour que le CMS. php.net est sans ambiguïté : il n'existe pas de mesures transitoires complètes, la mise à jour de PHP avec redémarrage de tous les processus est la seule voie sûre.
Pourquoi les faux conseils sont dangereux dans cette situation
Avec une faille critique qui attire beaucoup d'attention, un marché de solutions rapides apparaît. Les conseils sont partagés, raccourcis et transmis, souvent sans les restrictions de la source d'origine. Avec PHP2Shell s'ajoute le fait que des détails sont devenus connus avant la date officielle, selon des rapports, et que la situation était confuse les premiers jours.
Un faux conseil nuit doublement. Il laisse la faille ouverte et crée le sentiment d'avoir fait quelque chose. C'est précisément ce sentiment qui conduit à laisser de côté la véritable mise à jour. Certains conseils paralysent en outre votre propre site.
Neuf conseils passés au crible
Le tableau suivant résume ce que nous avons souvent lu ces derniers jours et lui oppose les affirmations des sources primaires.
| Conseil qui circule | Pourquoi il ne tient pas | Ce qui vaut à la place |
|---|---|---|
Bloquer toutes les requêtes avec PHPSESSID |
expressément rejeté par des experts ; paralyse connexions et paniers | mettre à jour PHP |
session.upload_progress.enabled=0 suffit |
selon des rapports spécialisés, ne ferme pas les deux failles | mesure transitoire judicieuse, la mise à jour reste obligatoire |
Définir des valeurs via ini_set() ou .user.ini |
php.net le déconseille expressément | côté serveur dans php.ini, le pool FPM ou la configuration du serveur |
| Masquer les messages d'erreur | selon php.net, error_reporting, display_errors ou @ n'aident pas |
mise à jour ; ne pas afficher publiquement les erreurs malgré tout |
Limiter la mémoire via RLIMIT_AS ou RLIMIT_DATA |
php.net avertit que cela peut précisément déclencher la situation vulnérable | limite via conteneur ou cgroup |
| Mettre à jour WordPress ou les extensions | la faille est dans l'interpréteur PHP, non dans le CMS | mettre à jour l'environnement d'exécution PHP |
| Cloudflare ou un autre WAF suffit | protection uniquement pour le trafic passant par le service ; les serveurs directement accessibles restent ouverts | WAF comme couche supplémentaire, non comme substitut |
| Recharger le service plutôt que le redémarrer | selon Red Hat, un rechargement ne suffit pas, les workers existants peuvent conserver l'ancien état | redémarrer complètement tous les workers |
| Corrigé veut dire propre | un correctif ne supprime pas un logiciel malveillant introduit auparavant | sauvegarder les journaux à partir du 20.10. et rechercher des traces |
Les trois erreurs les plus fréquentes expliquées plus en détail
L'interdiction des cookies
Le conseil de rejeter toutes les requêtes avec le cookie de session PHPSESSID semble technique et résolu. Des experts le rejettent expressément. En pratique, il casse tout ce qui a besoin d'une session : comptes clients, paniers, espaces d'administration, formulaires protégés contre la falsification. Ce n'est pas une protection contre la faille.
Le seul paramètre qui résout tout
session.upload_progress.enabled=0 figure dans les recommandations de php.net et est le remède cité contre CVE-2026-115560. Dans certains articles, cela est devenu « PHP2Shell désactivée ». Selon des rapports spécialisés, ce paramètre seul ne ferme toutefois pas les deux failles. De même, memory_limit=-1 ne supprime, selon php.net, que le déclencheur contrôlable ; une erreur de mémoire à un niveau plus profond peut toujours atteindre le chemin vulnérable. Sur PHP 8.5, fatal_error_backtraces=0 ne bloque, selon php.net, que la voie confirmée via les backtraces.
La manière de définir malgré tout ce paramètre correctement et durablement est décrite dans l'article Désactiver session.upload_progress. La liste complète des mesures transitoires figure sous Mesures immédiates sans correctif.
Le bouclier placé devant
Cloudflare a, selon ses propres indications, des règles de protection actives depuis le 21 octobre, y compris pour les clients de l'offre gratuite. Cloudflare signale lui-même des limites : la protection ne s'applique qu'au trafic qui passe par Cloudflare. Si le serveur d'origine est directement accessible, elle est contournée. De plus, Cloudflare examine aussi la réponse du serveur, car la requête seule ne suffit pas toujours. Pourquoi un WAF ne remplace pas la mise à jour, l'article WAF ou mise à jour l'explique.
Un conseil à risque : filtrer les requêtes d'envoi en périphérie
Tous les conseils gênants ne sont pas faux. Des experts proposent, comme mesure provisoire non officielle, de bloquer au niveau du proxy ou du WAF les requêtes multipart/form-data en dehors des véritables chemins d'envoi. Cela peut réduire la surface d'attaque, mais casse formulaires et envois de fichiers si la liste des chemins autorisés est incomplète.
Qui emprunte cette voie devrait la vérifier au préalable dans un environnement de test, la concerter avec les services métiers et la documenter comme mesure limitée dans le temps. Elle non plus ne remplace pas la mise à jour.
De nombreuses solutions WAF proposent pour cela un mode d'observation dans lequel les règles se contentent d'abord de journaliser au lieu de bloquer. Laissez une nouvelle règle tourner ainsi quelques jours et analysez quelles requêtes légitimes seraient touchées. Ce n'est qu'ensuite que vous passez au blocage. Vous évitez ainsi que des formulaires de candidature, des portails clients ou l'envoi d'images dans la boutique tombent en panne sans que personne ne s'en aperçoive.
Comment vérifier un conseil avant de l'appliquer
Quatre questions séparent les conseils utilisables des dangereux :
- Source : la recommandation vient-elle de php.net, de votre distribution, du BSI (office fédéral allemand de la sécurité des technologies de l'information) ou d'un expert nommément cité ?
- Prétention : la mesure est-elle décrite comme une transition ou comme une solution ? Avec PHP2Shell, seule la mise à jour est une solution.
- Effet secondaire : qu'est-ce qui casse lorsque la mesure s'applique ? Un conseil sans mention des effets secondaires est incomplet.
- Lieu d'application : le paramètre est-il défini côté serveur et de façon non écrasable, suivi d'un redémarrage de tous les workers ?
Consignez quelles mesures transitoires vous avez appliquées et quand. Vous pourrez ainsi les vérifier plus tard de façon ciblée et voir si une prétendue protection a retardé la véritable mise à jour.
Comment PHP SOS aide-t-il concrètement ?
- Nous examinons les mesures déjà appliquées chez vous et distinguons les efficaces des inefficaces.
- Nous installons la mise à jour de PHP, redémarrons tous les processus et prouvons l'état.
- Là où une mise à jour n'est pas encore possible, nous appliquons des mesures transitoires selon php.net, côté serveur et documentées.
- Avec le WAF et le correctif virtuel, nous complétons la protection en périphérie sans remplacer la mise à jour.
Questions fréquentes
Bloquer les requêtes contenant PHPSESSID protège-t-il ?
Non. Des experts rejettent expressément ce conseil qui circule. Il paralyse connexions, paniers et formulaires sans fermer la faille dans l'interpréteur.
session.upload_progress.enabled=0 suffit-il contre PHP2Shell ?
Non. Ce paramètre est l'une des diverses mesures transitoires et, selon des rapports spécialisés, ne ferme pas les deux failles. Il est judicieux, mais ne remplace pas la mise à jour de PHP.
Désactiver display_errors aide-t-il ?
Pas pour PHP2Shell. php.net souligne que masquer les diagnostics via error_reporting, display_errors ou l'opérateur @ n'aide pas. En production, display_errors devrait néanmoins être désactivé pour d'autres raisons.
À quoi reconnaître un conseil sérieux ?
Un conseil sérieux cite sa source, décrit ses limites et désigne les mesures transitoires comme telles. Qui promet qu'un seul paramètre rend la mise à jour superflue se trompe avec PHP2Shell.