PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619. They can let an attacker run their own code on a web server without logging in.

How do I check if my WordPress site is vulnerable to PHP2Shell?

Go to Tools, Site Health, Info tab, Server section in WordPress and read the PHP version. Your site is affected unless that version is 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a patched build from your distribution.

Will updating WordPress or installing a security plugin protect me from PHP2Shell?

No. The vulnerabilities are in the PHP interpreter, not in WordPress, and the attack can fire before any plugin code runs. Only updating PHP fixes it.

What should I do if my WordPress site runs on PHP 8.1 or older?

Switch to a supported PHP branch, because the PHP project has released no official fix for 8.1 and older. WordPress recommends PHP 8.3 or newer, and you should test the switch on a staging copy first.

PHP2Shell : ce que les propriétaires de sites WordPress doivent faire face aux vulnérabilités critiques de PHP

Key takeaways

PHP2Shell is two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a server without logging in. php.net fixed both on October 21, 2026, and every WordPress site runs on PHP, so every one needs a fixed version or a patched build. arvindkumar.ca
Check your site in Tools, Site Health, Info tab, Server. The PHP version there is the one that matters, and PHP SAPI shows how PHP runs (apache2handler, fpm-fcgi and litespeed are all at risk). arvindkumar.ca
Updating WordPress, themes or plugins does not help, and security plugins cannot block the attack, because the flaw sits underneath WordPress and fires before it loads. Only a PHP update fixes it. arvindkumar.ca
The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some distributions, such as Ubuntu, patch their own build without changing the version number, so check the distribution’s security notice for the two CVE numbers. arvindkumar.ca
On managed hosting, ask your host by name about PHP2Shell and both CVE numbers, then confirm in Site Health. On your own server, install the update, restart every PHP worker and repeat for every site. arvindkumar.ca
If you cannot update yet, some measures reduce exposure, such as turning off session upload progress and lowering post_max_size, but nothing short of the update makes a site safe. If none are possible, take the site offline or put it behind access control. arvindkumar.ca
PHP 8.1 and older get no official release, so move to PHP 8.3 or newer unless a distribution or host backports the fix. After patching, check for unexpected PHP files and admin accounts, and rotate the database password, salts and API keys if your site was exposed. arvindkumar.ca

Summarised from this post, formatted for answer engines.

Qu’est-ce que la vulnérabilité PHP2Shell?

PHP2Shell est le nom donné à deux vulnérabilités critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre à un attaquant d’exécuter son propre code sur un serveur web sans avoir à se connecter. php.net a corrigé les deux le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tous les sites WordPress roulent sur PHP, donc chacun doit utiliser l’une de ces versions, ou une version corrigée fournie par son hébergeur ou sa distribution Linux.

Dernière mise à jour le 22 octobre 2026, à 17 h 30, heure de Toronto. Les nouveaux développements sont ajoutés en haut de la chronologie ci-dessous.

Que s’est-il passé avec PHP2Shell, et quand?

On est passé de la recherche privée à une fuite, puis à des attaques et à un correctif d’urgence en environ une journée. Voici l’ordre des événements, du plus récent au plus ancien. Les heures sont en heure de Toronto, avec l’UTC entre parenthèses.

Passer la chronologie

Jeudi 22 octobre, 15 h 50 (19:50 UTC) : CloudLinux indique que PHP corrigé est maintenant dans ses dépôts stables pour toutes les versions touchées

CloudLinux a mis à jour sa page d’état : « Les paquets PHP natifs corrigés des dépôts de CloudLinux OS sont maintenant dans le canal stable pour toutes les versions touchées. » Natif signifie le PHP fourni avec le système d’exploitation lui-même : PHP 8.3 sur CloudLinux 10; 8.0, 8.1, 8.2 et 8.3 sur CloudLinux 9; 7.2, 7.3, 7.4, 8.0 et 8.2 sur CloudLinux 8; et PHP 5.4 sur CloudLinux 7 par l’entremise de TuxCare ELS. Plus tôt dans la journée, CloudLinux avait dit que la plupart de ces versions étaient encore en phase de test. Les paquets alt-php qu’utilisent la plupart des hébergeurs mutualisés ont été prêts les premiers : CloudLinux a indiqué à 21 h 19 (01:19 UTC) le 21 octobre que alt-php corrigé se trouvait dans ses dépôts stables pour CloudLinux 7, 8 et 9. À 10 h 31 (14:31 UTC), elle a expliqué que les paquets alt-php et ea-php corrigés contiennent un correctif rétroporté, et gardent donc un numéro de version PHP plus bas : « Ces paquets contiennent le correctif pour les deux CVE, même si le numéro de version de PHP est plus bas. » Pour vérifier un serveur, CloudLinux suggère d’exécuter rpm -q --changelog sur le paquet et de chercher les deux numéros de CVE ou, pour son PHP natif 8.2 et 8.3, rpm -q php-cli, qui devrait afficher 8.2.35 ou 8.3.36 ou une version ultérieure. Si vous êtes sur un hébergement mutualisé qui utilise CloudLinux, le correctif pour votre version de PHP devrait maintenant être accessible à votre hébergeur; demandez-lui s’il est installé.

Jeudi 22 octobre, 4 h 26 (08:26 UTC) : Kinsta affirme que tous les sites de sa plateforme ont le correctif PHP

Kinsta a marqué comme résolu l’incident sur sa page d’état : « Tous les sites sont protégés, les mises à jour de sécurité de PHP ont été déployées sur toute la plateforme. » Cela couvre toutes les versions de PHP offertes par Kinsta, de 7.4 à 8.5, qui étaient encore en cours de déploiement une minute plus tôt. Kinsta dit n’avoir aucune preuve d’intrusion liée aux vulnérabilités, et que ses règles de pare-feu Cloudflare et ses changements de configuration locale restent en place pour tous les sites jusqu’à nouvel ordre. Si votre site WordPress est chez Kinsta, vous n’avez rien à faire.

Mercredi 21 octobre, 17 h 15 (21:15 UTC) : AlmaLinux publie PHP corrigé pour AlmaLinux 8, 9 et 10

AlmaLinux a mis à jour son billet pour indiquer que les paquets PHP corrigés sont en cours de déploiement dans ses dépôts de production pour chaque flux PHP sur AlmaLinux 8, 9 et 10; vous n’avez donc plus besoin de son dépôt de test pour les obtenir. La mise à jour est datée de 17 h 15 (21:15 UTC) le 21 octobre, mais quand j’ai vérifié vers 20 h 15, le billet affichait encore « Patches in progress ». Elle a donc peut-être été publiée plus tard, et les miroirs peuvent mettre quelques heures à se synchroniser. AlmaLinux rétroporte les correctifs, donc le numéro de version de PHP ne change pas : le PHP par défaut d’AlmaLinux 10, par exemple, est corrigé dans la version de paquet php-8.3.33-1.el10_2.alma.1, et le flux php:8.3 sur AlmaLinux 9 dans php-8.3.33-1.module_el9.8.0+328+1fdeb728.alma.1. Elle a aussi corrigé d’anciens flux que Red Hat ne prend plus en charge, comme php:7.2, 7.3 et 8.0 sur AlmaLinux 8 et php:8.1 sur AlmaLinux 9, mais précise que les correctifs futurs pour ceux-ci ne sont pas garantis. Si votre site WordPress roule sur AlmaLinux, mettez à jour les paquets php avec dnf, redémarrez PHP-FPM (ou Apache, si vous utilisez mod_php), et vérifiez la version du paquet installé avec rpm -q php-common plutôt qu’avec php -v.

Jeudi 22 octobre, 2 h 44 (06:44 UTC) : Hostinger termine l’installation du correctif sur ses serveurs d’hébergement

Hostinger a mis à jour son billet pour indiquer qu’elle a terminé le déploiement de PHP corrigé à 2 h 44 (06:44 UTC) : « Le correctif de PHP est maintenant installé sur tous les serveurs d’hébergement de Hostinger, sauf les VPS. » Quand The Repository a fait le point sur les hébergeurs quelques heures plus tôt, Hostinger était encore en train de l’installer. Si votre site WordPress est sur un forfait Hostinger autre qu’un VPS, vous n’avez rien à faire. Les clients VPS gèrent leur propre PHP; sur un VPS Hostinger, mettre à jour PHP et le redémarrer reste donc votre responsabilité.

Mercredi 21 octobre, 21 h 20 (01:20 UTC le 22 octobre) : GoDaddy corrige Windows Hosting et commence avec ses serveurs Web Hosting

GoDaddy a de nouveau mis à jour son billet : « Nous avons corrigé toutes les versions de PHP sur Windows Hosting. Vous n’avez aucune action à effectuer. » Ses serveurs Web Hosting, qui attendaient un fournisseur lors de la mise à jour précédente, sont les prochains : « Nous avons reçu les correctifs de notre fournisseur et nous les déployons maintenant sur tous les serveurs Web Hosting. » GoDaddy dit que les mesures d’atténuation restent en place jusqu’à la fin du déploiement. Si votre site WordPress est sur GoDaddy Web Hosting, je vous suggère de vérifier la version de PHP dans Santé du site, Info, Serveur, ou de demander à GoDaddy si votre serveur est terminé.

Jeudi 22 octobre : le PDG de Cloudflare dit que les tentatives d’attaque PHP2Shell se chiffrent maintenant en millions

Le PDG de Cloudflare, Matthew Prince, a publié des chiffres sur le trafic d’attaque que voit Cloudflare. Selon l’article de The Register, Cloudflare a observé des milliers de tentatives d’exploitation dans les 10 heures précédant la divulgation des vulnérabilités, puis des dizaines de milliers en 45 minutes, des centaines de milliers en deux heures, puis des millions. Cybernews cite sa publication : « hundreds of thousands within 2 hours, and millions now. » The Register rapporte aussi que les attaquants modifient sans cesse leurs charges utiles pour contourner les règles de pare-feu de Cloudflare, et que Cloudflare a insisté sur le fait que ces règles ne remplacent pas l’application du correctif. Ce sont des tentatives, pas des intrusions confirmées, et je n’ai pas réussi à ouvrir moi-même la publication de Prince sur X; les chiffres sont donc les siens, tels que rapportés par ces deux médias. Si votre site n’utilise pas encore une version corrigée de PHP, partez du principe qu’il est sondé.

Mercredi 21 octobre, en soirée : Chainguard dit avoir publié son correctif plus tôt parce que des gens étaient déjà attaqués

Le récit de la PHP Foundation, plus bas dans cette chronologie, affirme que Chainguard a « unilatéralement rompu l’embargo » en publiant à 3 h 41 (07:41 UTC) le 21 octobre des images construites contenant le correctif. Le PDG de Chainguard, Dan Lorenc, a répondu dans l’article de The Register, publié à 20 h 02 (00:02 UTC le 22 octobre). Il a dit que Chainguard n’a « pas coulé l’information », qu’elle a appris le problème le vendredi précédent et trouvé les mêmes bogues de façon indépendante, et que « des gens se faisaient attaquer » avant la divulgation officielle, « alors nous avons décidé de publier les correctifs dans ce contexte ». Savoir qui avait raison, c’est une question pour le projet PHP et l’industrie de la sécurité. Pour les propriétaires de sites WordPress, ça ne change rien : mettez PHP à jour.

Jeudi 22 octobre, 3 h 04 (07 h 04 UTC) : SUSE corrige PHP sur ses anciennes versions d’entreprise, y compris PHP 7.4 et 8.0

SUSE a publié deux autres avis, SUSE-SU-2026:4843-1 et SUSE-SU-2026:4844-1, et sa page sur la CVE-2026-109618 énumère maintenant beaucoup plus de correctifs publiés. Sur SUSE Linux Enterprise Server 15 SP6-LTSS et SLES for SAP 15 SP6, PHP 8.2 est corrigé dans la version 8.2.35-150600.3.39.1 du paquet php8. Sur SLES 15 SP4-LTSS et SP5-LTSS, PHP 8.0 est corrigé dans la version 8.0.30-150400.4.80.1 du paquet. PHP 7.4, paquet en version 7.4.33-150400.4.81.1, est indiqué comme corrigé pour SLES 15 SP4 à SP7, même si la même page indique encore certains paquets PHP 7.4 comme étant en cours de test; vérifiez donc que votre outil de mise à jour l’offre. openSUSE Tumbleweed a PHP 8.5.12. Quand j’ai vérifié, la page ne mentionnait ni SUSE Linux Enterprise Server 16.0 ni openSUSE Leap; si vous utilisez l’un ou l’autre, gardez un œil sur la page de SUSE.

Jeudi 22 octobre, 0 h 38 (04 h 38 UTC) : d’autres hébergeurs WordPress font le point sur l’état de leurs correctifs

The Repository, une infolettre WordPress, a rassemblé des déclarations d’hébergeurs WordPress et de sociétés de sécurité, et j’ai vérifié celles que j’ai pu ouvrir. Hostinger dit installer le correctif de PHP sur chacun de ses serveurs et que les clients de tous les forfaits, sauf VPS, n’ont rien à faire; les clients VPS qui gèrent eux-mêmes leur PHP doivent le mettre à jour maintenant. La page d’état de Kinsta indiquait à 15 h 04 (19 h 04 UTC) le 21 octobre que PHP 8.3 et 8.5 corrigés étaient en cours de déploiement, et que 8.4, 8.2, 8.1 et 7.4 étaient encore en validation; The Repository rapporte que toutes les versions étaient en cours de déploiement à 19 h 25 (23 h 25 UTC). Bluehost dit que la plupart de ses serveurs sont corrigés et que, pendant qu’elle applique des mesures d’atténuation, les clients « peuvent constater des limites sur la taille des fichiers que vous pouvez téléverser ». Selon The Repository, WP Engine a terminé le déploiement de ses correctifs à 21 h 19 (01 h 19 UTC), et Wordfence a obtenu une exécution de code dans son laboratoire grâce à l’une des deux vulnérabilités, alors que l’autre faisait surtout planter ou redémarrer PHP. Wordfence recommande aussi de conserver les journaux du serveur et du pare-feu d’au moins 48 heures avant la publication. Sucuri dit que son pare-feu bloquait déjà certains des modèles d’attaque et qu’elle a ajouté d’autres règles, mais que « la protection d’un WAF ne remplace pas l’application des correctifs ».

Jeudi 22 octobre : Plesk corrige le PHP qui fait fonctionner son propre panneau de contrôle, dans Plesk Obsidian 18.0.81 Update 4

Plesk a de nouveau mis à jour son article de soutien; il affiche maintenant « Updated October 22, 2026 00:00 ». sw-engine, le PHP qui fait fonctionner le panneau Plesk lui-même, a maintenant un correctif : « Fixes for sw-engine (PHP engine used by Plesk itself) are already available in Plesk Obsidian 18.0.81 Update 4 », pour Plesk pour Linux comme pour Plesk pour Windows. Plesk indique que la version 18.0.81 jusqu’à l’Update 3, ainsi que la 18.0.80 Update 10 et les versions plus anciennes, sont touchées. Les serveurs sous 18.0.80 doivent encore attendre : Plesk dit « The fix for sw-engine in Plesk Obsidian 18.0.80 is still pending », prévu avec l’Update 11. C’est distinct des versions de PHP qui servent vos sites WordPress, que couvrent les entrées Plesk précédentes. Si vous gérez votre propre serveur Plesk, installez les mises à jour de Plesk et vérifiez qu’il indique 18.0.81 Update 4 ou une version plus récente.

Mercredi 21 octobre, 17 h 02 (21 h 02 UTC) : ELLIO compte 25 adresses qui envoient des attaques PHP2Shell, sans intrusion confirmée pour l’instant

ELLIO a maintenant publié son propre rapport, qui confirme le premier chiffre relayé par The Hacker News. La première requête PHP2Shell a atteint ses capteurs à 4 h 36 (08 h 36 UTC) le 21 octobre, cinq heures et demie avant que le correctif soit public, depuis un scanneur dont le user agent était php2shell-scan/109618. L’activité a augmenté après la publication : à 12 h 05 (16 h 05 UTC), une adresse a envoyé 49 requêtes d’attaque par épuisement de mémoire en vingt minutes, et à partir de 16 h 40 (20 h 40 UTC), une autre a atteint 123 de ses capteurs en dix-huit minutes. À 17 h 00 (21 h 00 UTC), 25 adresses avaient envoyé des requêtes PHP2Shell, qu’ELLIO regroupe en quelques familles d’outils plutôt qu’en 25 attaquants distincts. Certaines requêtes contiennent un chargeur qui télécharge un programme dans /tmp et l’exécute. ELLIO affirme aussi qu’« aucune source publique n’a encore signalé de compromission confirmée ». Son rapport énumère des signes à chercher dans vos journaux, que j’ai ajoutés à la section sur la vérification de l’état de votre site.

Mercredi 21 octobre : les notes de version de cPanel confirment un PHP corrigé dans EasyApache 4

Les notes de version d’EasyApache 4 25.91 de cPanel, datées du 21 octobre, indiquent que la version corrige les CVE-2026-109618 et CVE-2026-109619 dans ses paquets ea-php74 à ea-php85. C’est la confirmation par cPanel de ce que GoDaddy et InMotion Hosting avaient rapporté plus tôt, et elle couvre PHP 7.4, 8.0 et 8.1, qui ne reçoivent aucune version officielle du projet PHP. Les notes n’énumèrent pas les versions corrigées des paquets, et le journal détaillé des modifications d’EasyApache 4 n’était pas à jour quand j’ai vérifié. Si vous gérez votre propre serveur cPanel, exécutez les mises à jour d’EasyApache 4 dans WHM, puis redémarrez Apache et PHP-FPM.

Jeudi 22 octobre : VulnCheck compte plus d’un million d’hôtes exposés avec un PHP sans correctif officiel

The Hacker News a rassemblé d’autres chiffres provenant de sociétés de sécurité. Selon son rapport, VulnCheck a trouvé PHP sur 2 608 039 hôtes accessibles depuis Internet : plus de 700 000 utilisent PHP 3.x à 7.3 et environ 400 000 utilisent PHP 7.4 à 8.1, des versions qui ne reçoivent aucune version officielle, contre 403 000 sur les versions prises en charge, 8.2 à 8.5. VulnCheck a aussi repéré deux hôtes qui scannent avec le user agent php2shell-scan/109618. ELLIO dit que la première requête PHP2Shell a atteint ses capteurs à 4 h 36 (08 h 36 UTC) le 21 octobre, moins d’une heure après la publication des images corrigées de Chainguard, et Pantheon, qui héberge des sites WordPress et Drupal, dit avoir bloqué plus de 60 000 requêtes suspectes qui sondaient la vulnérabilité. Je n’ai pas encore vu les rapports de ces sociétés; considérez donc les chiffres comme les leurs, relayés par The Hacker News.

Jeudi 22 octobre : Amazon Linux 2 a un PHP 8.2 corrigé pour les deux vulnérabilités

Les pages de suivi d’Amazon pour CVE-2026-109618 et CVE-2026-109619 concordent maintenant. Quand j’ai vérifié vers 2 h 55, les deux indiquaient PHP 8.2 des Amazon Linux 2 Extras comme corrigé dans ALAS2PHP8.2-2026-015, ainsi que php8.2 à php8.5 sur Amazon Linux 2023, et aucune ne montrait de paquet « Pending Fix ». Le paquet php du dépôt principal d’Amazon Linux 2, et php8.1 sur Amazon Linux 2023, sont toujours « No Fix Planned ».

Mercredi 21 octobre, 18 h 36 (22 h 36 UTC) : Amazon dit que PHP2Shell est maintenant largement exploité, et qu’il a été essayé pour la première fois le 17 octobre

Le chef de la sécurité d’Amazon, CJ Moses, a écrit sur l’AWS Security Blog que MadPot, le réseau de pots de miel d’Amazon, a enregistré une tentative d’exploitation le 17 octobre, quatre jours avant la divulgation des vulnérabilités, depuis une adresse IP d’un réseau commercial d’anonymisation. Amazon dit que cela laisse penser à un acteur malveillant, et qu’on ne sait pas comment il a obtenu les détails aussi tôt. Elle a vu plusieurs exploits de preuve de concept à partir d’environ 22 h (02 h UTC) le 20 octobre, alors que le correctif était encore sous embargo, et d’autres dans les heures suivant la publication, qu’elle a vus utilisés contre ses capteurs « presque immédiatement ». Son verdict : « PHP2Shell is now being broadly exploited in the wild. » C’est une affirmation plus forte que celle de Huntress à 16 h 30, quand elle n’avait vu aucune attaque sur les systèmes de ses partenaires. Amazon dit que la mise à niveau de PHP est le seul correctif complet. D’ici là, elle suggère de bloquer les téléversements de fichiers multipart après avoir vérifié ce que cela casse, de chercher les requêtes POST qui contiennent PHP_SESSION_UPLOAD_PROGRESS, et de vérifier sur les serveurs la présence de processus inattendus ou de fichiers modifiés. Elle dit aussi de commencer toute enquête à partir du 17 octobre, et non du 21 octobre.

Mercredi 21 octobre : Amazon Linux 2023 a maintenant des paquets corrigés pour PHP 8.2 à 8.5

Les pages d’avis d’Amazon se chargent maintenant, et chacune énumère les deux CVE. Sur Amazon Linux 2023, les versions corrigées des paquets sont php8.2 8.2.35-1.amzn2023.0.1 dans ALAS2023-2026-3301, php8.3 8.3.36-1.amzn2023.0.1 dans ALAS2023-2026-3302, php8.4 8.4.27-1.amzn2023.0.1 dans ALAS2023-2026-3303 et php8.5 8.5.12-1.amzn2023.0.1 dans ALAS2023-2026-3304. Cela règle la question de php8.5 de ma dernière entrée : la page de suivi de la CVE-2026-109619 indique maintenant php8.5 comme corrigé aussi, de même que php8.5 sur l’Amazon Linux 2027 Preview, dans ALAS2027-2026-243. Cette page montre encore php8.2 sur Amazon Linux 2023 comme « Pending Fix », mais l’avis php8.2 lui-même nomme les deux CVE. php8.1 est toujours « No Fix Planned ». N’oubliez pas d’installer avec sudo dnf upgrade --releasever=latest, puis de redémarrer PHP-FPM ou Apache.

Mercredi 21 octobre, en soirée (22 octobre UTC) : Amazon Linux 2023 livre un PHP corrigé

Amazon Linux a commencé à livrer ses correctifs. Son outil de suivi de sécurité indique maintenant les paquets php8.2, php8.3 et php8.4 sur Amazon Linux 2023 comme « Fixed », dans les avis ALAS2023-2026-3301, 3302 et 3303, datés du 22 octobre en UTC. Les deux pages de CVE de l’outil de suivi ne concordent pas encore pour le reste. La page de la CVE-2026-109618 indique php8.5 comme corrigé aussi, dans ALAS2023-2026-3304, alors que la page de la CVE-2026-109619 dit encore « Pending Fix » pour ce paquet. Pour PHP 8.2 des Amazon Linux 2 Extras, c’est l’inverse : corrigé dans ALAS2PHP8.2-2026-015 sur la page de la CVE-2026-109619, encore en attente sur l’autre. Les pages d’avis elles-mêmes ne se chargeaient pas quand j’ai essayé; je ne peux donc pas encore donner les versions corrigées des paquets. php8.1 sur Amazon Linux 2023, et le paquet php du dépôt principal d’Amazon Linux 2, sont indiqués « No Fix Planned ». Si votre site WordPress tourne sur Amazon Linux 2023, notez que chaque serveur est verrouillé sur sa version, de sorte qu’un simple dnf upgrade peut répondre « Nothing to do ». La documentation d’Amazon utilise sudo dnf upgrade --releasever=latest pour installer les mises à jour de la dernière version; redémarrez ensuite PHP-FPM ou Apache.

Mercredi 21 octobre : Red Hat corrige PHP sur RHEL 10

Red Hat a publié deux autres avis, tous deux classés Important, qui corrigent les deux vulnérabilités sur Red Hat Enterprise Linux 10, y compris les abonnements Extended Update Support et Extended Life Cycle de la version 10.2. RHSA-2026:87070 corrige le paquet php par défaut, PHP 8.3, avec la version 8.3.36-1.el10_2, et RHSA-2026:87071 corrige le paquet php8.4 avec la version 8.4.27-1.el10_2. Les deux corrigent aussi une troisième vulnérabilité, moins grave, CVE-2026-91765, un déni de service dans l’analyseur SOAP de PHP. Cela comble la lacune de RHEL 10 que j’avais signalée dans les entrées précédentes sur Red Hat. AlmaLinux, une distribution gratuite conçue pour être compatible avec RHEL, a indiqué à 10 h 36 (14 h 36 UTC) que ses correctifs pour AlmaLinux 8, 9 et 10 étaient en cours, avec des paquets de test attendus plus tard dans la journée. Quand j’ai vérifié vers 20 h 15, son billet affichait toujours « Patches in progress ». Si votre serveur roule sous AlmaLinux, gardez un œil sur ce billet.

Mercredi 21 octobre : SUSE publie un correctif pour SLES 15 SP7, mais Amazon Linux n’en a pas encore

La page de SUSE sur CVE-2026-109618 indique maintenant un correctif publié pour SUSE Linux Enterprise Server 15 SP7, son édition SAP et son module Web and Scripting, avec le paquet php8 en version 8.3.36-150700.3.24.1. Le correctif pour SUSE Linux Enterprise Server 16.0, PHP 8.4.27, est toujours indiqué comme en cours, et les paquets php7 de SUSE ainsi qu’openSUSE Leap sont toujours indiqués comme touchés. Amazon Linux n’a publié aucun correctif : son suivi de sécurité indique php8.2, php8.3, php8.4 et php8.5 sur Amazon Linux 2023, ainsi que PHP 8.2 des Extras d’Amazon Linux 2, comme « Pending Fix », et php8.1 sur Amazon Linux 2023 comme « No Fix Planned ». Un membre de l’équipe Amazon Linux a répondu sur GitHub : « We are aware of those Critical CVEs and actively working on delivering an update asap. » Si votre site WordPress roule sur Amazon Linux 2023 avec PHP 8.1, je planifierais dès maintenant le passage à PHP 8.3 plutôt que d’attendre un correctif qui ne viendra pas.

Mercredi 21 octobre, 16 h 40 (20 h 40 UTC) : Huntress n’a toujours pas vu d’attaques sur les systèmes qu’elle surveille

Huntress, dont je mentionne plus bas les conseils pour repérer une intrusion, a mis à jour son analyse : « As of October 21 at 4:30pm ET, Huntress has not observed in-the-wild exploitation on partner systems. » Elle a aussi noté que plusieurs chercheurs, dont Calif et Wiz, ont maintenant publié les détails techniques des vulnérabilités. Les rapports continuent donc de diverger : Patchstack a signalé des incidents d’exploitation confirmés tôt ce matin-là, Hadrian a signalé une exploitation « à grande échelle », et watchTowr a dit à SecurityWeek avoir vu des tentatives, mais aucune réussie. Maintenant que les détails sont publics, je ne compterais pas sur le fait que ça dure. Ça ne change rien à ce qu’il faut faire : mettre PHP à jour.

Mercredi 21 octobre : OVHcloud affirme que l’hébergement partagé reçoit automatiquement un PHP corrigé, mais que les VPS et les serveurs dédiés relèvent de leurs propriétaires

OVHcloud a publié un billet sur les deux vulnérabilités à l’intention des clients qui gèrent leurs propres serveurs. On y lit : « WebCloud and shared hosting customers will automatically get an updated PHP component. » Les clients VPS et Bare Metal sont laissés à eux-mêmes : OVHcloud dit ne pas toucher à leurs serveurs sans leur consentement. Ils doivent donc mettre PHP à jour vers une version corrigée, puis redémarrer PHP, ce qu’OVHcloud appelle « the step most often forgotten ». Si votre site WordPress est sur un VPS ou un serveur dédié d’OVHcloud, ce travail vous revient.

Mercredi 21 octobre, 16 h 18 (20 h 18 UTC) : CloudLinux commence à distribuer un PHP corrigé pour les serveurs d’hébergement partagé

CloudLinux, le système d’exploitation derrière de nombreux serveurs d’hébergement partagé, a écrit sur sa page d’état : « Fixed packages for the versions below are already available in our stable repositories. » Sur CloudLinux et AlmaLinux 8 et 9, les premières versions corrigées sont alt-php 5.2, 5.6, 7.4, 8.0 et 8.4, avec des listes semblables pour CloudLinux 6, 7 et 10, Ubuntu, Debian et Alpine. alt-php 8.1, 8.2, 8.3 et 8.5 sur CloudLinux 8 et 9 ne figuraient pas sur cette liste. CloudLinux a indiqué que les versions restantes étaient déployées en continu, la majeure partie étant attendue vers 17 h 15 (21 h 15 UTC) et alt-php 8.5 vers 18 h 30 (22 h 30 UTC). Une mise à jour de paquets ordinaire les installe; une mise à jour réservée à la sécurité ne les verra pas tant que CloudLinux n’aura pas ajouté les données de l’avis. Quand j’ai vérifié vers 18 h 20, la page n’avait pas de mise à jour plus récente. C’est la version qu’InMotion Hosting disait attendre pour ses serveurs partagés, de revendeur et WordPress. Si vous êtes en hébergement partagé, je demanderais donc à votre hébergeur si l’alt-php corrigé pour votre version de PHP est déjà installé.

Mercredi 21 octobre : Red Hat corrige PHP 8.3 sur RHEL 9 et PHP 7.4 sur RHEL 8

Red Hat a publié deux autres avis, tous deux classés Important. RHSA-2026:87079 corrige les deux vulnérabilités dans le flux de module php:8.3 sur Red Hat Enterprise Linux 9, avec le paquet php en version 8.3.36-1, y compris les abonnements Extended Update Support et Extended Life Cycle de la version 9.8. RHSA-2026:87080 les corrige dans le flux de module php:7.4 sur RHEL 8 et RHEL 8.10 Extended Life Cycle, avec le paquet php en version 7.4.33-8. PHP 7.4 ne reçoit plus de version du projet PHP, donc c’est exactement le genre de rétroportage de fournisseur que php.net conseillait de demander aux utilisateurs d’anciennes versions de PHP. Je n’ai pas encore vu d’avis de Red Hat pour RHEL 10, ni pour ses autres flux PHP sur RHEL 8 et 9.

Mercredi 21 octobre, 15 h 30 (19 h 30 UTC) : GoDaddy corrige Managed WordPress, mais son hébergement partagé attend

GoDaddy a mis à jour son billet sur les vulnérabilités : « We have patched all PHP versions on Managed Hosting for WordPress », donc ces clients n’ont rien à faire. Ses serveurs Web Hosting et Windows Hosting ne sont pas encore corrigés. GoDaddy dit attendre que son fournisseur livre des versions corrigées des paquets PHP personnalisés utilisés par ces serveurs, avoir ajouté des mesures d’atténuation en attendant, et appliquer le correctif dès l’arrivée des paquets. Les clients VPS gèrent leur propre PHP et doivent le mettre à jour eux-mêmes; pour ceux qui utilisent cPanel, GoDaddy dit que cPanel a ajouté des versions corrigées de PHP à EasyApache 4, comme ea-php82 8.2.35, et rétroporté le correctif dans ses paquets PHP 7.4, 8.0 et 8.1. InMotion Hosting décrit une répartition semblable : ses serveurs dédiés sont corrigés, tandis que ses serveurs partagés, de revendeur et WordPress attendent les paquets alt-php de CloudLinux. Si vous êtes en hébergement partagé, où que ce soit, je demanderais si votre serveur a déjà le PHP corrigé, ou seulement des mesures d’atténuation.

Mercredi 21 octobre : Automattic et SiteGround disent à leurs clients WordPress qu’il n’y a rien à faire

Deux grands hébergeurs WordPress se sont adressés à leurs clients. À 12 h 16 (16 h 16 UTC), Automattic a écrit : « If your site is hosted on WordPress.com, WordPress VIP, WP Cloud, Pressable, or Tumblr, your site is already protected. » Elle dit avoir travaillé étroitement avec l’équipe de sécurité de PHP pour protéger ces sites le plus tôt possible, et « There is nothing you need to do. » Elle n’explique ni comment, ni quelles versions de PHP ces plateformes utilisent maintenant. SiteGround a publié plus tôt, à 7 h 30 (11 h 30 UTC), avant la sortie du correctif. Elle a dit avoir déployé des règles d’atténuation au niveau des serveurs sur tous ses serveurs, que « We disabled the affected functionalities on all supported PHP versions », et que les clients n’ont rien à faire. Elle a promis de mettre le billet à jour une fois la version de PHP publiée; quand j’ai vérifié, ce n’était pas fait. php.net affirme que les mesures autres que la mise à jour ne rendent pas une installation sûre. Si vous êtes chez SiteGround, je chercherais donc une version corrigée de PHP dans Site Health dès que SiteGround la confirmera.

Mercredi 21 octobre : Debian publie son correctif pour Debian 12

Debian a publié l’avis de support à long terme DLA-4848-1, qui corrige les deux vulnérabilités dans Debian 12 (bookworm) avec le paquet php8.2 en version 8.2.35-1~deb12u1. Debian 12 était la lacune dans les correctifs de Debian : après la correction de Debian 13, son paquet php8.2 était toujours indiqué comme vulnérable. La page de suivi de Debian pour CVE-2026-109618 l’indique maintenant comme corrigé. La page de CVE-2026-109619 n’était pas encore à jour quand j’ai vérifié, mais l’avis couvre les deux.

Mercredi 21 octobre : Plesk corrige ses anciennes versions de PHP et Plesk pour Windows

Plesk a de nouveau mis à jour son article de soutien. Ses versions PHP 7.4, 8.0 et 8.1 pour Linux ont maintenant des correctifs, mais elles gardent les mêmes numéros de version, 7.4.33, 8.0.30 et 8.1.34 : selon les mots de Plesk, « Versions built on 21 October 2026 have fixes included. » Plesk pour Windows a maintenant des versions corrigées de PHP 8.2, 8.3, 8.4 et 8.5, soit 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Le correctif pour sw-engine, le PHP qui fait rouler le panneau Plesk lui-même, est toujours prévu sous forme de correctifs à chaud 18.0.80#11 et 18.0.81#4.

Mercredi 21 octobre : Google Cloud précise que les clients doivent appliquer eux-mêmes les correctifs de leur PHP

Google Cloud a publié sa réponse aux deux vulnérabilités, rédigée par son CISO, Chris Betz, et par Raluca Ada Popa de Google DeepMind. « Bien que Google Cloud ne soit pas lui-même vulnérable, les utilisateurs de PHP qui s’exécute sur Google Cloud peuvent l’être », peut-on y lire. App Engine standard sur PHP 8.2 ou une version plus récente est mis à jour automatiquement, mais App Engine flexible, Cloud Run et les fonctions Cloud Run sans mises à jour automatiques de l’image de base, ainsi que les images de conteneurs sur GKE, doivent être reconstruits et redéployés. Les solutions du Marketplace nécessitent une mise à jour de la part de leur fournisseur, ou une mise à jour de PHP. « Les images de conteneurs que vous construisez vous-mêmes relèvent de votre responsabilité », ajoute Google, et « les environnements d’exécution non pris en charge ne seront pas corrigés ». Si votre site WordPress tourne sur Google Cloud à partir d’une image du Marketplace ou de votre propre conteneur, vérifiez qui met à jour son PHP.

Mercredi 21 octobre : le Centre canadien pour la cybersécurité publie un avis

Le Centre canadien pour la cybersécurité a publié l’avis AV26-1070. Il indique que PHP 8.5 avant 8.5.12, 8.4 avant 8.4.27, 8.3 avant 8.3.36 et 8.2 avant 8.2.35 sont touchés, et il encourage les utilisateurs et les administrateurs à lire l’avis de php.net et à appliquer les mises à jour. Il ne nomme que les quatre branches prises en charge, mais les versions plus anciennes de PHP sont touchées elles aussi : les avis de php.net couvrent toutes les versions antérieures aux versions corrigées. Le Centre ne dit pas si les vulnérabilités sont exploitées.

Mercredi 21 octobre : watchTowr affirme qu’aucune attaque n’a encore réussi

watchTowr a déclaré à SecurityWeek que ses capteurs avaient repéré les premières tentatives d’exploitation à peu près au moment de la publication des correctifs, mais qu’aucune n’avait fonctionné. « Même si personne n’a réussi jusqu’à maintenant, nous ne nous attendons pas à ce que ça dure », a affirmé Jake Knott, son responsable du renseignement sur les menaces. D’autres entreprises décrivent un tableau plus sombre. Selon le même article, Hadrian a affirmé, quelques heures avant les correctifs : « Nous constatons maintenant une exploitation de php2shell à grande échelle dans la nature », surtout par la route de progression du téléversement de session, et Vega a observé des tentatives qui utilisaient du code de preuve de concept public. L’article de SecurityWeek ne donne aucun chiffre.

Mercredi 21 octobre : les agences américaines demandent de mettre à jour, ou de mettre les systèmes hors ligne

La NSA, le FBI et la CISA ont toutes exhorté les organisations à corriger les deux vulnérabilités, selon Nextgov, et ont averti que les systèmes devraient être mis hors ligne s’ils ne peuvent pas être sécurisés rapidement. L’avis de la NSA indique que les vulnérabilités « offrent souvent une voie directe vers le système de fichiers ou la base de données du serveur », recommande de mettre un système hors ligne « jusqu’à ce qu’il puisse être entièrement protégé » si une mise à jour immédiate n’est pas possible, et précise que la NSA « fera bientôt un suivi avec des directives plus précises ». L’alerte de la CISA disait qu’elle n’avait observé aucune exploitation des vulnérabilités au moment de la publication.

Mercredi 21 octobre : Red Hat publie un correctif pour PHP 8.2 sur RHEL 9

Red Hat a publié l’avis de sécurité RHSA-2026:87072, classé Important, qui corrige les deux vulnérabilités dans le flux de module php:8.2 sur Red Hat Enterprise Linux 9, avec le paquet php version 8.2.35-1. Il couvre RHEL 9 ainsi que ses abonnements 9.8 Extended Update Support et Extended Life Cycle. Je n’ai pas encore vu d’avis de Red Hat pour ses autres flux PHP, ni pour RHEL 8 et 10.

Mercredi 21 octobre : la PHP Foundation explique comment l’embargo a été rompu

La PHP Foundation a publié son compte rendu de la publication. Elle explique que le problème de mémoire insuffisante est apparu pour la première fois pendant qu’un développeur du noyau corrigeait un problème issu d’un audit externe de 2024, puis que le correctif est resté en suspens pendant des mois; selon ses mots, « le retard était une défaillance structurelle ». Sa chronologie indique que les numéros CVE ont commencé à circuler vers 11 h (15 h UTC) le 20 octobre, que Calif a publié par erreur une vidéo de sa preuve de concept vers 16 h (20 h UTC), et que Chainguard a publié des images construites contenant le correctif à 3 h 41 (7 h 41 UTC) le 21 octobre, plus de six heures avant la publication coordonnée. Le code de preuve de concept s’est répandu rapidement après la fuite, mais la Foundation affirme que l’équipe de sécurité de PHP « n’a repéré aucun exploit fonctionnel au moment de la publication ou de la divulgation publique ». Elle modifie la façon dont l’équipe de sécurité décide, de sorte qu’une majorité puisse trancher sur un correctif difficile et que la direction intervienne plus tôt quand un dossier piétine. Son conseil : « Si vous utilisez PHP, il est impératif de faire la mise à jour maintenant. »

Mercredi 21 octobre : watchTowr observe maintenant des tentatives d’exploitation

L’entreprise de sécurité watchTowr, dont la FAQ indiquait plus tôt dans la journée qu’aucune attaque n’avait été observée dans la nature, a publié une nouvelle page sur PHP2Shell où elle dit « observer des tentatives d’exploitation actives de CVE-2026-109618 et de CVE-2026-109619 ». Elle n’a donné ni chiffres ni cibles. Elle a aussi prévenu que la progression du téléversement de session « n’est pas la seule voie d’exploitation », et que les modifications apportées aux fichiers .ini « doivent être considérées comme inefficaces » pour bloquer les attaques.

Mercredi 21 octobre : Ubuntu publie son correctif

Ubuntu a publié l’avis de sécurité USN-8948-1, qui corrige les deux vulnérabilités dans ses versions prises en charge :

Ubuntu 24.04 : paquet php8.3 version 8.3.6-0ubuntu0.24.04.13.
Ubuntu 22.04 : paquet php8.1 version 8.1.2-1ubuntu2.28.
Ubuntu 26.04 : paquet php8.5 version 8.5.4-0ubuntu1.5, et Ubuntu 26.10 : 8.5.9-0ubuntu2.1.
Ubuntu 20.04, 18.04, 16.04 et 14.04 : corrigées par Ubuntu Pro dans USN-8948-2.

Le billet de blogue d’Ubuntu sur les correctifs indique que les mises à jour de sécurité automatiques devraient les installer en moins de 24 heures, mais tout ce qui exécute PHP doit quand même être redémarré, par exemple Apache pour mod_php, ou encore le serveur au complet. Les pages de suivi par CVE d’Ubuntu affichaient toujours « Needs evaluation » au moment où je les ai consultées, mais les deux avis énumèrent les paquets corrigés.

Mercredi 21 octobre : Plesk publie une version corrigée de PHP pour les serveurs Linux

Plesk, un panneau de contrôle que de nombreux hébergeurs utilisent pour faire fonctionner des sites WordPress, a mis à jour son article de soutien sur les deux vulnérabilités pour indiquer que « Fixes for Plesk for Linux are already available » pour ses versions de PHP 8.2, 8.3, 8.4 et 8.5, soit 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Ses versions de PHP 7.4, 8.0 et 8.1 « don’t have fixes yet », et « Fixes for Plesk for Windows are not available yet. » Le PHP intégré de Plesk, sw-engine, qui fait fonctionner le panneau de contrôle lui-même, est aussi touché; Plesk prévoit le corriger dans les correctifs 18.0.80#11 et 18.0.81#4.

Mercredi 21 octobre : Debian publie son correctif pour Debian 13

Debian a publié l’avis de sécurité DSA-6574-1, qui corrige les deux vulnérabilités dans Debian 13 (trixie) avec la version 8.4.27-1~deb13u1 du paquet php8.4. Debian 12 (bookworm) n’est pas encore couvert : le suivi de sécurité de Debian indique toujours que son paquet php8.2 est vulnérable, sans version corrigée.

Mercredi 21 octobre : OpenAI donne sa version des faits

OpenAI a publié un billet sur la divulgation coordonnée. « To our knowledge, frontier AI found these vulnerabilities before attackers did », peut-on y lire, et l’entreprise parle de « one of the most impactful security issues in recent memory ». Elle affirme que ces bogues font partie de « several significant vulnerabilities » qu’elle a découvertes et qu’elle s’emploie à corriger, qu’elle partage un vérificateur de version de PHP et une compétence Codex pour aider à repérer les versions vulnérables, et que « For organizations using PHP, the priority now is applying the fixes. »

Mercredi 21 octobre, 10 h (14 h UTC) : le correctif est publié

php.net a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, en précisant qu’elles « fix two critical vulnerabilities that can allow unauthenticated remote code execution », et a diffusé un avis de sécurité. Les points principaux :

Qui est à risque : « all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. » php.net considère que le risque est le plus élevé pour mod_php, « with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs. »
CVE-2026-109618, « RCE via OOM corruption » : si PHP manque de mémoire pendant qu’il prépare encore une requête, il peut laisser derrière lui des données à moitié construites, que l’étape de nettoyage traite comme valides. Des attaquants peuvent pousser PHP dans cet état avec des requêtes multipart/form-data conçues pour l’occasion, le format que les navigateurs utilisent pour le téléversement de fichiers. php.net a validé une exécution de code à distance complète par HTTP contre mod_php avec les limites par défaut.
CVE-2026-109619, « RCE via stale global state » : certaines données de requête peuvent survivre après la libération de leur mémoire, et la requête suivante traitée par le même processus PHP peut les utiliser. Les voies confirmées passent par la progression du téléversement de session, activée par défaut, et par les traces d’appels des erreurs fatales dans PHP 8.5. Un site n’a pas besoin d’utiliser les sessions pour que la voie de la progression du téléversement fonctionne.
Anciennes versions de PHP : 8.1 et les versions antérieures n’ont pas de publication officielle, mais « given the severity », l’équipe de sécurité a publié des correctifs minimaux du code source pour PHP 7.4, 8.0 et 8.1 à l’intention de ceux qui compilent PHP eux-mêmes.
Paquets : les distributions Linux et les fournisseurs de soutien à long terme ont reçu les correctifs à l’avance. Le dépôt Remi, géré par des bénévoles, « will not have updates today », et php.net a exhorté ses utilisateurs à passer aux paquets de leur distribution ou à compiler à partir du code source.
Mesures provisoires : php.net a énuméré des mesures partielles pour ceux qui ne peuvent pas mettre à jour tout de suite, en précisant bien qu’elles « do not make an installation safe ». Elles sont décrites dans la section « impossible de mettre à jour tout de suite » plus bas.

Mercredi 21 octobre, 9 h 56 (13 h 56 UTC) : Cloudflare publie les détails

Quelques minutes avant le correctif, Cloudflare a expliqué ce qu’elle avait déployé et ce qu’elle observait. Elle a dit avoir « observed attack traffic targeting our customers » et que les attaquants modifiaient leurs charges utiles pour contourner ses règles. Les points principaux :

Forfait gratuit : sept règles, « Generic Rules – Anomalous Execution » 1 à 7, dans le Cloudflare Managed Free Ruleset. Les clients du forfait gratuit n’ont rien à faire.
Pro, Business et Enterprise : les mêmes sept règles dans le Cloudflare Managed Ruleset. Cloudflare demande à ces clients de confirmer que l’ensemble de règles est déployé en mode blocage.
Une deuxième ligne de défense : une nouvelle règle pour tous les forfaits, y compris le gratuit, qui vérifie ce que le serveur renvoie et bloque une réponse correspondante avant qu’elle n’atteigne l’attaquant.
Les limites : « Les données de la requête ne suffisent pas toujours à distinguer une attaque d’un trafic légitime », a écrit Cloudflare, ajoutant que « les clients doivent corriger leurs dépôts PHP même avec la protection d’un WAF ». Pour l’hébergement géré : « Si un hébergeur gère PHP, demandez-lui d’appliquer la mise à jour de sécurité. »

Mercredi 21 octobre, 9 h 44 (13 h 44 UTC) : WordPress.org demande aux propriétaires de sites de mettre PHP à jour

WordPress.org a publié un article sur WordPress News, signé John Blackbourn : « En raison de la gravité critique des failles, nous encourageons les propriétaires de sites à mettre à jour PHP immédiatement. » On y précise que les vulnérabilités « ne sont pas propres à WordPress » et qu’« aucune mise à jour de WordPress n’est requise ni prévue pour ces failles ». L’article invite les propriétaires de sites à vérifier auprès de leur hébergeur, même si certains hébergeurs peuvent déjà être en train de mettre PHP à jour ou d’ajouter des règles de pare-feu. Il ajoute que quiconque exploite son propre serveur avec une version de PHP antérieure à 8.2 devrait envisager de le mettre hors ligne jusqu’à la mise à niveau de PHP, reprenant le même conseil que le NCSC du Royaume-Uni.

Mercredi matin : Cloudflare confirme des attaques précoces

Le directeur technique de Cloudflare, Dane Knecht, a publié sur X : « Nous voyons apparaître des attaques précoces et nous mettons à jour les mesures d’atténuation à mesure que de nouveaux vecteurs se présentent. » Il a indiqué que « les règles sont offertes à tous les clients, y compris ceux du forfait gratuit », les a qualifiées de solution temporaire et a demandé à tout le monde d’appliquer le correctif dès que PHP publierait la mise à jour.

Mercredi 21 octobre, 3 h 34 (07 h 34 UTC) : premiers signalements d’attaques

Patchstack, une entreprise de sécurité WordPress, a mis à jour son alerte : « plusieurs incidents d’exploitation active confirmés ». D’autres firmes, dont watchTowr, n’avaient pas encore confirmé d’attaques réelles à ce moment-là. Le NCSC du Royaume-Uni a demandé aux organisations de se préparer à des mises à jour immédiates de PHP et d’envisager de mettre leurs systèmes hors ligne s’ils ne pouvaient pas être protégés.

Pendant la nuit : une solution de contournement circule, puis est retirée

Des chercheurs qui épluchaient le code source de PHP ont suggéré de désactiver le suivi de progression des téléversements de session, session.upload_progress.enabled, comme mesure temporaire. Vers 1 h (05 h UTC), GMO Flatt Security, qui avait d’abord laissé entendre que cela pouvait aider, a rétropédalé en avertissant que des attaques contournant ce réglage étaient à prévoir. Gina Peter Banyard, développeuse du noyau de PHP, a déclaré : « la seule mesure d’atténuation, c’est de corriger ou de mettre à niveau PHP ». php.net a ensuite classé ce réglage parmi plusieurs mesures partielles; voir l’entrée de 10 h.

Mardi 20 octobre, 23 h 02 (03 h 02 UTC le 21 octobre) : Cloudflare active la protection

Cloudflare, qui a collaboré à la divulgation coordonnée avec la PHP Foundation, OpenAI, Wiz et d’autres, affirme avoir activé automatiquement la protection par pare-feu pour les clients de tous les forfaits à partir de ce moment, des heures avant la publication du correctif. Les sites du forfait gratuit étaient protégés sans aucune intervention.

Mardi 20 octobre : php.net devance le correctif d’une journée

php.net a publié un préavis : « La publication est prévue le mercredi 21 octobre 2026 à 14 h UTC. Elle corrige deux vulnérabilités critiques, toutes deux notées 9,2 selon CVSS v4.0. » Le préavis demandait à tous les utilisateurs de PHP de « se préparer dès maintenant » et se réservait le droit de publier plus tôt si les détails devenaient publics ou si des attaques apparaissaient. Le même jour, l’avis 2026-018 du CERT-UE a demandé aux organisations de se préparer à appliquer le correctif immédiatement et, lorsque ce n’était pas possible, d’envisager d’isoler les applications exposées à Internet.

Mardi 20 octobre : les détails fuitent

Une publication sur Hacker News affirmait que deux vulnérabilités critiques d’exécution de code à distance dans PHP étaient sur le point d’être divulguées. Elle a été supprimée, mais des captures d’écran ont circulé sur X et Mastodon. La fuite annonçait un score CVSS de 10,0; PHP a ensuite noté chacune des failles à 9,2. La firme de sécurité watchTowr a confirmé que les informations qui avaient fuité étaient authentiques, en ajoutant : « Nous étions censés attendre jusqu’à jeudi, 11 h HE. »

Avant le 20 octobre : découvertes par des chercheurs, avec l’aide de l’IA

Les vulnérabilités ont été découvertes et signalées en privé. OpenAI a écrit par la suite que la firme de sécurité Calif avait trouvé l’une d’elles à l’aide du modèle GPT-5.6 Sol d’OpenAI, dans le cadre de l’initiative Patch the Planet d’OpenAI, et que la firme de sécurité Wiz avait trouvé et signalé les deux vulnérabilités de façon indépendante. Les deux avis de php.net (CVE-2026-109618, CVE-2026-109619) créditent quatre personnes ayant signalé les failles, et l’analyse de Cloudflare nomme aussi Calif.io et Quarkslab comme codivulgateurs. L’équipe de PHP a préparé le correctif sous embargo, avec une divulgation publique prévue le jeudi 22 octobre.

Mon site WordPress est-il touché par PHP2Shell?

Oui, à moins que la version de PHP qui le sert soit l’une des versions corrigées ou une version corrigée fournie par votre distribution. WordPress vous donne les deux renseignements dont vous avez besoin au même endroit : allez dans Outils, Santé du site, onglet Info, section Serveur.

La version de PHP est celle qui sert vos pages, et c’est celle qui compte. La commande php -v en ligne de commande affiche la version CLI, qui peut être une installation différente.
PHP SAPI vous indique comment PHP s’exécute. apache2handler signifie Apache avec mod_php, le risque le plus élevé. fpm-fcgi signifie PHP-FPM, où php.net a validé la voie de session de CVE-2026-109619. litespeed correspond à LiteSpeed, que php.net signale aussi comme à risque. Un risque plus faible n’est pas un risque nul; mettez-les tous à jour.

Que signifie PHP2Shell pour les sites WordPress en particulier?

Cela signifie que les défenses habituelles de WordPress ne s’appliquent pas, parce que le code vulnérable se trouve sous WordPress et que l’attaque peut se déclencher avant même le chargement de WordPress. Cinq conséquences en découlent :

Mettre à jour WordPress, les thèmes ou les extensions ne règle rien. Patchstack indique que les vulnérabilités se trouvent « dans l’interpréteur PHP, et non dans une application en particulier ». Seule une mise à jour de PHP corrige le problème.
Les extensions de sécurité ne peuvent pas le bloquer. Une extension de pare-feu WordPress est du code PHP qui s’exécute à l’intérieur de l’interpréteur vulnérable, et l’exploit démontré par php.net se déclenche avant l’exécution de tout code d’application. Une extension de sécurité peut tout de même vous aider à repérer une intrusion après coup.
Tous les sites WordPress sont atteignables. La page de connexion, les commentaires, l’API REST et admin-ajax.php acceptent tous des requêtes de n’importe qui, et PHP traite chacune d’elles. Une extension de mode maintenance n’aide pas non plus : la requête atteint PHP avant que le code de l’extension ne s’exécute.
Vous ne pouvez pas simplement désactiver les téléversements. L’attaque utilise le même format multipart/form-data dont WordPress a besoin pour la médiathèque, les téléversements de l’éditeur de blocs et tout formulaire comportant un champ de fichier.
Les vieilles versions de PHP sont courantes sur les sites WordPress. WordPress fonctionne encore sur PHP 7.4, même s’il recommande la version 8.3 ou plus récente; rien dans WordPress n’oblige donc un site à abandonner une version en fin de vie, et ces versions ne reçoivent aucune version officielle.

Ce n’est pas qu’une théorie pour WordPress. Wiz, l’une des équipes qui ont découvert les vulnérabilités, affirme avoir réussi une exécution de code à distance sans connexion contre l’image Docker officielle de WordPress, wordpress:latest, avec chacune des deux vulnérabilités. L’équipe l’a d’abord confirmé sur WordPress le 21 août 2026, avant de signaler les vulnérabilités à PHP le 24 août. Calif, une autre des équipes, place WordPress 7.1.2 parmi les applications où elle a confirmé l’exécution de code à distance sans connexion, et indique que WordPress atteint le code vulnérable « par de simples appels à maybe_unserialize() », la fonction que WordPress utilise pour décompresser les options et les métadonnées stockées.

WordPress.org a maintenant publié ses propres consignes, et elles concordent avec celles de php.net : mettez PHP à jour dès maintenant. On y lit : « Aucune mise à jour de WordPress n’est requise ni prévue pour ces failles », donc rien à attendre du côté de WordPress lui-même. On vous demande aussi de vérifier auprès de votre hébergeur, même s’il est peut-être déjà en train de mettre PHP à jour ou d’ajouter des règles de pare-feu, et on renvoie au même écran Santé du site décrit plus haut pour vérifier votre version de PHP.

Quelles versions de PHP corrigent PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent les deux vulnérabilités, et elles se trouvent sur la page de téléchargements de php.net. Les avis de php.net pour CVE-2026-109618 et CVE-2026-109619 indiquent que toutes les versions antérieures sont touchées.

PHP 8.5 : passez à la version 8.5.12 ou à une version ultérieure.
PHP 8.4 : passez à la version 8.4.27 ou à une version ultérieure.
PHP 8.3 : passez à la version 8.3.36 ou à une version ultérieure.
PHP 8.2 : passez à la version 8.2.35 ou à une version ultérieure. php.net rappelle à tous que la version 8.2 arrive en fin de vie le 31 décembre 2026; prévoyez donc le passage à la version 8.3 ou plus récente.
PHP 8.1, 8.0, 7.4 et les versions plus anciennes : aucune version officielle. Voyez la section sur les vieilles versions de PHP plus bas.

Le numéro de version ne dit pas toujours tout. Certaines distributions corrigent leur propre build sans changer le numéro de version de PHP. Ubuntu 24.04, par exemple, fournit PHP sous la version 8.3.6 et le corrige en modifiant la version du paquet, pas celle de PHP; Santé du site affichera donc toujours 8.3.6 une fois le correctif d’Ubuntu installé. Ubuntu a maintenant publié ce correctif dans USN-8948-1 : sur Ubuntu 24.04, la version corrigée du paquet est 8.3.6-0ubuntu0.24.04.13, et le même avis couvre Ubuntu 22.04, 26.04 et 26.10. Ubuntu 20.04 et les versions plus anciennes reçoivent le correctif par Ubuntu Pro, dans USN-8948-2. Debian a publié ses correctifs pour Debian 13, paquet php8.4 version 8.4.27-1~deb13u1, dans DSA-6574-1, et pour Debian 12, paquet php8.2 version 8.2.35-1~deb12u1, dans DLA-4848-1. Red Hat a corrigé les flux de module php:8.2 et php:8.3 sur RHEL 9, paquets en versions 8.2.35-1 dans RHSA-2026:87072 et 8.3.36-1 dans RHSA-2026:87079, ainsi que le flux php:7.4 sur RHEL 8, paquet en version 7.4.33-8, dans RHSA-2026:87080. Sur RHEL 10, Red Hat a corrigé le paquet php, version 8.3.36-1.el10_2, dans RHSA-2026:87070, et le paquet php8.4, version 8.4.27-1.el10_2, dans RHSA-2026:87071. SUSE a corrigé SUSE Linux Enterprise Server 15 SP7, paquet php8 version 8.3.36-150700.3.24.1, et 15 SP6-LTSS, paquet php8 version 8.2.35-150600.3.39.1, selon sa page pour CVE-2026-109618, qui indique aussi des correctifs pour PHP 8.0 et 7.4 sur ses anciennes versions à support à long terme. Amazon Linux a publié des correctifs pour ses paquets php8.2, php8.3, php8.4 et php8.5 sur Amazon Linux 2023, en versions 8.2.35-1.amzn2023.0.1, 8.3.36-1.amzn2023.0.1, 8.4.27-1.amzn2023.0.1 et 8.5.12-1.amzn2023.0.1, dans les avis ALAS2023-2026-3301 à ALAS2023-2026-3304. PHP 8.2 provenant des Extras d’Amazon Linux 2 est aussi corrigé, dans ALAS2PHP8.2-2026-015. Sur Amazon Linux 2023, installez-les avec sudo dnf upgrade --releasever=latest, comme le montre la documentation d’Amazon, car un simple dnf upgrade reste sur la version actuelle du serveur. AlmaLinux a corrigé tous les flux PHP sur AlmaLinux 8, 9 et 10 en conservant le numéro de version de PHP : sur AlmaLinux 10, par exemple, le PHP par défaut est corrigé dans la version de paquet php-8.3.33-1.el10_2.alma.1. Si votre PHP provient d’une distribution, consultez son avis de sécurité pour les deux numéros CVE et comparez les versions de paquets.

Que dois-je faire aujourd’hui?

Installez une version corrigée de PHP sur le serveur qui héberge votre site, puis confirmez-le depuis WordPress.

Sur l’hébergement WordPress géré

Demandez à votre hébergeur si votre serveur exécute déjà PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version corrigée, et sinon, à quel moment ce sera le cas. Nommez PHP2Shell et les deux numéros CVE. Ça a fonctionné si on vous donne une heure ou une confirmation, et non une vague assurance.
Passez à la version corrigée dans le paramètre PHP du panneau d’hébergement, si votre hébergeur ne le fait pas automatiquement. Ça a fonctionné si Santé du site, Info, Serveur affiche le nouveau numéro, ou si votre hébergeur confirme la version corrigée.
Chargez la page d’accueil, connectez-vous et envoyez un formulaire de test. Ça a fonctionné si aucune erreur n’apparaît; une version de sécurité au sein de la même branche ne devrait pas changer le comportement de votre site.

Certains hébergeurs ont déjà répondu publiquement à la première question. Automattic affirme que les sites sur WordPress.com, WordPress VIP, WP Cloud et Pressable sont déjà protégés, et que les clients n’ont rien à faire. SiteGround affirme avoir déployé des règles d’atténuation au niveau du serveur sur tous ses serveurs avant la sortie du correctif. GoDaddy affirme avoir corrigé toutes les versions de PHP de son Managed Hosting for WordPress et de son Windows Hosting, et déployer maintenant le correctif sur ses serveurs Web Hosting, avec des mesures d’atténuation en place jusqu’à la fin du déploiement. OVHcloud affirme que ses clients en hébergement mutualisé recevront automatiquement un PHP à jour, alors que les clients de ses serveurs VPS et Bare Metal doivent mettre PHP à jour eux-mêmes. Hostinger affirme que son correctif est maintenant installé sur tous les serveurs sauf les VPS, Kinsta affirme que le correctif PHP est maintenant déployé sur toute sa plateforme, et Bluehost affirme que la plupart de ses serveurs sont corrigés. La plupart de ces publications n’indiquent pas quelle version de PHP votre site utilise actuellement, alors je vous conseille tout de même de vérifier Santé du site, Info, Serveur dès que possible.

Sur votre propre serveur

Installez la mise à jour de votre distribution en suivant son avis de sécurité pour CVE-2026-109618 et CVE-2026-109619, ou compilez la version 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 à partir du code source. Ça a fonctionné si la version du paquet correspond à l’avis, ou si php -v affiche la version corrigée.
Redémarrez tous les processus PHP : PHP-FPM, Apache si vous utilisez mod_php, ou LiteSpeed. D’ici là, l’ancien code continue de traiter les requêtes. Ça a fonctionné si Santé du site affiche la nouvelle version, ou si les processus PHP-FPM ont démarré après la mise à jour.
Répétez l’opération pour chaque version de PHP et chaque site du serveur, y compris les anciennes copies de préproduction et les installations de test. Ça a fonctionné si la Santé du site de chaque site affiche une version corrigée.

Trois remarques selon la plateforme. Si vous installez PHP depuis le dépôt Remi, passez aux paquets de la distribution ou compilez à partir du code source, comme le conseille php.net. Si vous exécutez PHP dans Docker, téléchargez la nouvelle image, reconstruisez vos propres images avec docker build --pull et recréez les conteneurs. Si vous utilisez un panneau de contrôle comme cPanel ou Plesk, ses versions de PHP suivent le calendrier de l’éditeur du panneau, alors consultez son avis. Pour cPanel, les notes de version de cPanel indiquent qu’EasyApache 4 25.91 corrige les deux vulnérabilités dans ses paquets ea-php74 à ea-php85, ce qui couvre aussi PHP 7.4, 8.0 et 8.1. Si vous gérez votre propre serveur cPanel, exécutez les mises à jour d’EasyApache 4 dans WHM, puis redémarrez Apache et PHP-FPM. Sur Plesk pour Linux, des versions corrigées de PHP 8.2 à 8.5 sont disponibles : installez les mises à jour de Plesk, puis allez dans Tools & Settings, PHP Settings, où le nom de chaque gestionnaire indique sa version. Plesk a aussi corrigé ses versions de PHP 7.4, 8.0 et 8.1 pour Linux, mais elles gardent les mêmes numéros de version (7.4.33, 8.0.30 et 8.1.34); vérifiez donc que la date de compilation, qu’affiche phpinfo(), est le 21 octobre 2026, plutôt que la version. Plesk pour Windows propose maintenant des versions corrigées de PHP 8.2 à 8.5. sw-engine, le PHP qui fait tourner le panneau Plesk lui-même, est corrigé dans Plesk Obsidian 18.0.81 Update 4; sur 18.0.80, le correctif est toujours en attente avec l’Update 11. Si votre hébergeur utilise Imunify360, CloudLinux affirme que son jeu de règles WAF 8.83 bloque la forme de l’exploit public sur les serveurs où le WAF d’Imunify360 est activé, comme solution temporaire et non comme correctif. Sur les serveurs CloudLinux, les paquets alt-php, ea-php et PHP natif corrigés sont maintenant dans les dépôts stables de CloudLinux pour toutes les versions touchées : une mise à jour ordinaire des paquets les installe, alors qu’une mise à jour limitée à la sécurité peut ne pas les voir tant que CloudLinux n’a pas ajouté les données de l’avis. Les paquets alt-php et ea-php corrigés gardent un numéro de version de PHP plus bas; vérifiez donc la présence des deux numéros CVE avec rpm -q --changelog plutôt que de vous fier à la version. Redémarrez ensuite PHP.

Que faire si je ne peux pas mettre PHP à jour tout de suite?

Vous pouvez fermer certaines des voies d’attaque connues, mais rien d’autre que la mise à jour ne rend un site sûr. Selon php.net, ces mesures « réduisent l’exposition à certaines voies d’attaque, mais ne rendent pas une installation sûre ». watchTowr, qui observe maintenant des tentatives d’exploitation, va plus loin : selon elle, les modifications aux fichiers .ini « doivent être considérées comme inefficaces » pour bloquer les attaques. La plupart des mesures de php.net sont des paramètres du serveur; sur un hébergement géré, c’est donc le travail de votre hébergeur, et sur votre propre serveur, le vôtre.

Pour CVE-2026-109619, la vulnérabilité d’état périmé :

Désactivez le suivi de progression des téléversements de session et redémarrez tous les processus. Ce réglage doit se trouver dans php.ini, le pool PHP-FPM ou la configuration du serveur; php.net dit de ne pas se fier à ini_set() ni à un fichier .user.ini de PHP-FPM. Cela bloque les voies de session confirmées, pas toutes les variantes, et l’avis suggère de le laisser désactivé après le correctif si vous ne l’utilisez pas.
Sur PHP 8.5, désactivez aussi les traces d’appels des erreurs fatales et redémarrez tous les processus. Cela bloque seulement la voie confirmée passant par les traces d’appels.
Supprimez les paramètres PHP invalides ou obsolètes appliqués à chaque requête, car ils émettent des avertissements avant l’initialisation de la requête, et php.net précise que masquer ces avertissements n’aide pas. Sur les sites WordPress, cherchez dans .htaccess d’anciennes lignes php_value et php_flag laissées par d’anciennes extensions ou d’anciens hébergeurs.
Corrigez les erreurs fatales et les délais d’attente que les visiteurs peuvent déclencher, comme le téléversement ou l’importation d’une extension qui plante. Votre journal d’erreurs PHP, ou wp-content/debug.log quand WP_DEBUG_LOG est activé, les montre.

session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

Pour CVE-2026-109618, la vulnérabilité de manque de mémoire :

Réglez memory_limit à -1 de façon que les applications ne puissent pas le modifier, par exemple avec php_admin_value dans le pool PHP-FPM ou la configuration d’Apache. Cela supprime l’échec de limite de mémoire que les attaquants peuvent provoquer, même si php.net note qu’un échec d’allocation sous-jacent peut tout de même atteindre le bogue. WordPress ne la rabaissera pas : dans le code de WordPress 7.1.3, le réglage de mémoire au démarrage et wp_raise_memory_limit() laissent tous deux intacte une limite illimitée. Combinez-le avec une limite de mémoire de conteneur ou de cgroup pour qu’une seule requête ne puisse pas faire tomber le serveur, et n’utilisez pas RLIMIT_AS ni RLIMIT_DATA, qui, selon php.net, peuvent déclencher le bogue.
Abaissez post_max_size : 8M pour les sites qui n’acceptent aucun téléversement, 32M s’ils en acceptent, avec upload_max_filesize en dessous. La plupart des sites WordPress acceptent des téléversements, alors 32M est la valeur réaliste, et les téléversements de médias plus volumineux échoueront tant que vous n’aurez pas appliqué le correctif. Santé du site, Info, Serveur affiche les deux valeurs.
Appliquez aussi des limites au niveau du serveur web ou du proxy : taille des requêtes, nombre de champs de saisie, parties multipart et en-têtes, y compris pour les requêtes qui arrivent sans Content-Length utilisable.

; PHP-FPM pool, for example /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_value[session.upload_progress.enabled] = 0

À la périphérie, devant PHP :

Si votre site est derrière Cloudflare, vérifiez que les règles fonctionnent pour vous. Avec le forfait Free, elles sont déjà activées et il n’y a rien à faire. Avec Pro, Business et Enterprise, confirmez que le Cloudflare Managed Ruleset est déployé en mode blocage. Considérez ces règles comme une mesure temporaire, comme le fait Cloudflare, et assurez-vous que personne ne peut joindre votre serveur directement et contourner le CDN.
Si vous pouvez restreindre /wp-admin/ et l’API REST à vos propres adresses IP au niveau du CDN ou du serveur web, vous pouvez bloquer les requêtes multipart/form-data partout ailleurs sur le site jusqu’à ce que vous appliquiez le correctif. Ne le faites pas si des visiteurs téléversent des fichiers par un formulaire.
Quand rien de tout cela n’est possible, mettez le site hors ligne ou placez-le derrière un contrôle d’accès au niveau du serveur web ou du CDN, comme le recommandent le CERT-EU, le NCSC et la National Security Agency des États-Unis. Occupez-vous d’abord des sites oubliés : anciennes copies de préproduction, microsites abandonnés et installations de test sur le même serveur.

Que faire si mon site WordPress tourne sur PHP 8.1 ou une version plus ancienne?

Il faut alors passer à une branche prise en charge, parce que PHP 8.1 et les versions antérieures ne reçoivent aucune version officielle du projet PHP. Les correctifs sources publiés par php.net pour 7.4, 8.0 et 8.1 s’adressent à ceux qui compilent PHP eux-mêmes. Certaines distributions Linux et certains fournisseurs de support à long terme rétroportent les correctifs vers des versions plus anciennes; si votre PHP vient de l’un d’eux, posez-leur la question. Ubuntu, par exemple, a corrigé PHP 8.1 sur Ubuntu 22.04, et PHP 7.4 sur Ubuntu 20.04 pour les abonnés Ubuntu Pro. Red Hat a corrigé PHP 7.4 sur RHEL 8, Plesk a reconstruit ses PHP 7.4, 8.0 et 8.1 avec le correctif pour les serveurs Linux, et CloudLinux propose maintenant des paquets PHP corrigés dans ses dépôts stables pour chaque version touchée, y compris 7.4, 8.0 et 8.1. SUSE indique des paquets PHP 7.4 et 8.0 corrigés pour ses anciennes versions de SUSE Linux Enterprise Server 15. AlmaLinux a corrigé ses flux php:7.2, 7.3 et 8.0 sur AlmaLinux 8 et php:8.1 sur AlmaLinux 9, tout en précisant que les correctifs futurs ne sont pas garantis pour eux. cPanel a corrigé ses paquets ea-php74 à ea-php85 dans EasyApache 4 25.91, ce qui couvre aussi PHP 7.4, 8.0 et 8.1. Tous les fournisseurs ne le feront pas, cependant : Amazon Linux indique pour son paquet php8.1 sur Amazon Linux 2023 « No Fix Planned ». Pour presque tout le monde, la solution consiste à changer de version de PHP chez votre hébergeur.

WordPress recommande PHP 8.3 ou une version plus récente, et je choisirais cette option plutôt que 8.2, dont le support de sécurité prend fin le 31 décembre 2026; 8.3 est pris en charge jusqu’au 31 décembre 2027. Testez d’abord le changement sur une copie de préproduction. Si un plugin ou un thème ne fonctionne plus sous 8.3, corrigez-le ou remplacez-le. L’autre option, c’est de continuer à exposer une vulnérabilité d’exécution de code à distance connue, que selon Amazon, on exploite maintenant à grande échelle.

Comment vérifier si mon site WordPress a déjà été touché?

Cherchez du PHP qui fait quelque chose qu’un serveur web ne devrait jamais faire, et des fichiers qui ne devraient pas exister. Les conseils de Huntress ciblent les processus PHP (php-fpm, php-cgi, apache2 ou httpd) qui lancent des shells ou des outils comme sh, bash, curl, wget ou nc. Ensuite, les vérifications habituelles pour WordPress :

Des fichiers PHP nouveaux ou modifiés dans la racine web, surtout dans wp-content/uploads, qui devrait contenir des médias, pas du PHP.
Des comptes administrateur que vous n’avez pas créés, sous Utilisateurs.
Des tâches cron que vous ne reconnaissez pas, sur le serveur et dans WordPress.
Des rafales d’erreurs de mémoire insuffisante ou de plantages de processus PHP dans le journal d’erreurs, autour de requêtes POST vers des pages qui ne reçoivent aucun téléversement. CVE-2026-109618 fonctionne en épuisant la mémoire de PHP, alors ces signes méritent un examen plus attentif.
Des requêtes POST dans les journaux de votre serveur web qui contiennent PHP_SESSION_UPLOAD_PROGRESS, ce qu’Amazon suggère de rechercher.
Des requêtes avec l’agent utilisateur php2shell-scan/109618, des délimiteurs multipart contenant ----p2s, ou le texte JACKALPOC, que ELLIO présente comme des signes d’outils d’analyse et d’exploitation PHP2Shell. En trouver signifie que quelqu’un a essayé, pas qu’il a réussi à entrer.

WP-CLI compare les fichiers du noyau et des plugins avec les copies officielles et liste ce qui diffère :

wp core verify-checksums
wp plugin verify-checksums --all

Si vous trouvez quelque chose, isolez le site, conservez les journaux du serveur web et de PHP, et restaurez à partir d’une sauvegarde propre une fois PHP mis à jour, pas avant, sinon la même porte reste ouverte.

Ne rien trouver n’exclut pas une fuite. Wiz affirme que des attaquants pouvaient aussi lire des données sensibles dans la mémoire de PHP, « y compris des mots de passe, des jetons et des clés d’API », sans avoir besoin d’exécuter du code sur le serveur, et une fuite de ce genre ne laisse rien à trouver pour les vérifications de fichiers ci-dessus. Sur un site WordPress, cette mémoire contient à chaque requête le mot de passe de la base de données ainsi que les clés et les sels de wp-config.php. Amazon recommande de commencer les enquêtes à partir du 17 octobre, date de la première tentative qu’elle a observée; donc si votre site n’était pas corrigé à un moment quelconque depuis, je changerais le mot de passe de la base de données, je générerais de nouveaux sels (wp config shuffle-salts le fait en une seule commande) et je remplacerais les clés d’API enregistrées dans les réglages des plugins, comme celles des services SMTP, de paiement et de sauvegarde, une fois PHP mis à jour. De nouveaux sels déconnectent tout le monde, et c’est ce que vous voulez.

Tout le travail d’aujourd’hui se résume à une ligne dans Santé du site : la version de PHP, comparée à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou au paquet corrigé de votre distribution. Avec un hébergement géré, posez la question à votre hébergeur et vérifiez cette ligne quand il dit que c’est fait. Sur votre propre serveur : mettez à jour, redémarrez chaque processus, vérifiez chaque site.