En bref : qui veut voir la faille PHP2Shell fermée dès aujourd'hui a besoin de quatre choses : la bonne mise à jour, le redémarrage de tous les processus PHP, la recherche de code malveillant déjà introduit et une preuve. Vous êtes concerné ? Appelez-nous. Nous vous aidons. Nous prenons cela en charge à distance, dès le premier message.
Ne supprimez rien et ne réinstallez rien pour l'instant. Même pour un correctif, la règle est la même : d'abord sécuriser, ensuite modifier. Si quelque chose est déjà entré, nous avons besoin de l'état des fichiers et des journaux. Signaler une urgence, et nous définirons l'ordre avec vous.
Pourquoi la faille ne peut pas attendre
Les deux failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans PHP lui-même et permettent d'exécuter du code malveillant à distance, sans authentification. Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) a déclaré le niveau d'alerte 3 (orange) et recommande la mise à jour immédiate. Si elle n'est pas possible tout de suite, les serveurs web doivent être retirés temporairement du réseau. Selon des articles de presse, les premières tentatives d'attaque ont été observées avant même la publication des correctifs le 21 octobre 2026. Cloudflare a observé des tentatives et déployé des règles de protection, mais prévient que des règles fondées sur les seules données de la requête ne suffisent pas.
Important pour les exploitants : une mise à jour du CMS ne ferme pas la faille PHP. Selon des rapports, WordPress.org ne prévoit pas non plus de mise à jour à ce sujet, car la faille se trouve dans l'interpréteur. Elle ne se ferme qu'au niveau de PHP, donc dans ce que votre serveur exécute réellement.
Ce que vous faites tout de suite
- Connaître la version cible. Sont corrigées PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.2 atteint la fin de la prise en charge le 31 décembre 2026 ; prévoyez-le dans votre planification.
- Recenser tous les systèmes. Y compris les serveurs de test, les images de conteneurs et les anciens systèmes joignables depuis Internet.
- Clarifier les responsabilités. Pour les offres d'hébergement et les serveurs gérés, c'est le fournisseur qui applique la mise à jour. Interrogez-le par écrit sur la version et le redémarrage.
- Conserver les journaux. À partir du 20 octobre 2026, selon la presse spécialisée.
- Convenir d'une fenêtre. Un redémarrage interrompt brièvement les requêtes en cours. Fixez un moment où quelqu'un peut prendre des décisions.
- Ne pas attendre si elle est ouverte. Si le correctif ne peut pas être appliqué immédiatement, examinez avec nous l'isolement ou les mesures transitoires.
Comment PHP SOS aide-t-il concrètement ?
- Faire le point : nous recensons les systèmes, les versions de PHP, les modes d'exécution, les hébergeurs et l'accessibilité, et nous fixons l'ordre : d'abord les systèmes les plus exposés.
- Sécuriser et fermer : nous sécurisons l'état actuel, appliquons la mise à jour ou amenons l'hébergement à l'état dont le correctif est démontré, puis nous redémarrons tous les processus. Pour les conteneurs, nous reconstruisons l'image et la déployons.
- Examiner et nettoyer : comme un correctif ne supprime pas le code malveillant, nous recherchons des signes d'une intrusion antérieure et nettoyons si nécessaire.
- Durcir et rendre compte : vous recevez une preuve écrite par système, ainsi que des recommandations pour que la prochaine mise à jour se déroule plus vite. Le service de correctifs PHP décrit l'offre.
Mise à jour, redémarrage, preuve : ce qui compte
L'erreur la plus fréquente est une mise à jour sans redémarrage. Tant que d'anciens processus tournent en mémoire, le code vulnérable reste actif, même si les fichiers sont à jour. Le mode d'emploi se trouve sur la page Redémarrer PHP-FPM et tous les workers. La deuxième erreur est de croire l'affichage : les distributions et les hébergeurs fournissent souvent des backports, et le numéro de version reste alors identique. Le journal des modifications du paquet avec les numéros CVE est fiable ; dans la famille Debian, avec apt-get changelog <paket>.
De plus, selon le manuel PHP, la nouvelle directive memory_hard_limit_percent existe depuis les versions de sécurité. Une version de PHP qui ne la connaît pas est concernée. Le test est court :
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Il doit être exécuté pour chaque version et chaque mode d'exécution, car la ligne de commande peut utiliser une autre version de PHP que le serveur web. Pour finir, nous consignons le résultat afin que vous puissiez le présenter à votre hébergeur, à votre assureur ou à votre donneur d'ordre.
Si la mise à jour n'est pas possible tout de suite
Il y a des raisons pour lesquelles une mise à jour n'est pas possible aujourd'hui : une ancienne application qui ne fonctionne pas avec les versions plus récentes de PHP, un hébergeur sans autorisation, une image de conteneur dans un pipeline figé. Pour ces cas, php.net indique des mesures transitoires qui ne constituent expressément pas une protection complète : définir memory_limit=-1 de façon que les applications ne puissent pas l'écraser, limiter post_max_size, session.upload_progress.enabled=0 et, sur PHP 8.5, fatal_error_backtraces=0, chacun suivi d'un redémarrage. S'y ajoutent des règles de protection en périphérie, qui ne remplacent pas une mise à jour. Un conseil qui circule, consistant à bloquer toutes les requêtes contenant PHPSESSID, est expressément rejeté par les auteurs spécialisés.
Nous discutons au préalable des mesures adaptées à votre système et de ce qu'elles peuvent casser. Plus de détails sur la page Mesures immédiates si vous ne pouvez pas encore appliquer le correctif et sur le thème WAF et correctif virtuel. Pour PHP 8.1 et les versions antérieures, la situation est particulière ; elle est décrite sous PHP 8.1 et antérieur : ce qui s'applique maintenant.
Ce que vous devriez nous envoyer
- La liste des serveurs et des hébergeurs, si elle existe
- Le résultat de
php -vpour chaque système et une indication du mode d'exécution - L'indication de l'utilisation de conteneurs, de Plesk, de cPanel ou d'une offre gérée
- La fenêtre souhaitée et une personne de contact pour les redémarrages
- Les anomalies constatées depuis le 17 octobre 2026
Pourquoi PHP SOS
Nous travaillons Made in Germany et, avec notre réseau de partenaires de professionnels de la cybersécurité, nous sommes spécialisés depuis plus de 25 ans dans la sécurité informatique. Vous avez un interlocuteur unique, qui accompagne la mise à jour, vérifie le redémarrage et livre la preuve. Nous travaillons à distance, sans déplacement, et documentons chaque étape. Nous ne promettons pas de miracles : un correctif ferme la faille, mais il ne prouve pas que rien ne s'est produit auparavant, et nous vous le disons tel quel.
Vous êtes concerné ? Appelez-nous. Nous vous aidons.
Ne laissez pas la faille ouverte plus longtemps. Appelez-nous ou écrivez-nous sur WhatsApp. Nous prenons le relais dès le premier message et restons à vos côtés jusqu'à ce que l'incident soit clos et documenté. Signaler une urgence maintenant.
Questions fréquentes
Puis-je fermer moi-même la faille de sécurité PHP ou ai-je besoin d'aide ?
Une mise à jour est à la portée d'un administrateur, mais sujette aux erreurs : il faut cibler la version qui sert réellement les pages et redémarrer tous les processus. Qui a plusieurs serveurs, des images de conteneurs ou un hébergeur aux particularités gagne du temps et évite des erreurs avec de l'aide.
PHP doit-il être redémarré après la mise à jour ?
Oui. De nouveaux fichiers ne suffisent pas tant que d'anciens processus PHP tournent en mémoire. Tous les workers, ou tous les processus, doivent être redémarrés ; avec mod_php, c'est le serveur web.
Que faire s'il n'existe pas encore de mise à jour pour ma version de PHP ?
Pour PHP 8.1 et les versions antérieures, le projet PHP ne publie plus de mises à jour officielles. Il faut alors un backport du fournisseur dont le correctif est démontré, une migration vers une version maintenue ou des mesures transitoires, qui n'offrent toutefois pas de protection complète.
Suffit-il de définir session.upload_progress.enabled sur 0 ?
Non. Selon des rapports spécialisés, ce paramètre seul ne referme pas les deux failles ; la mise à jour de PHP reste obligatoire. Ne le définissez que dans php.ini, le pool FPM ou la configuration du serveur, pas par ini_set() ou .user.ini.
Comment savoir que la faille est réellement fermée ensuite ?
Par une preuve sur le système en service : la version ou le journal des modifications du paquet, un test sur la nouvelle directive memory_hard_limit_percent et la confirmation que tous les processus ont été redémarrés après la mise à jour.