Vulnérabilités critiques de PHP : ce que les propriétaires de sites WordPress doivent savoir

English version: Critical PHP Vulnerabilities: What WordPress Site Owners Need to Know

PHP a corrigé deux failles de sécurité critiques le 21 octobre 2026. La mise à jour de WordPress ou des extensions ne les résout pas. Découvrez comment vérifier si votre environnement d'hébergement est concerné et quelles sont les mesures à prendre.

En bref : que s'est-il passé ?

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques du runtime PHP, CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon CVSS v4.0. Dans certaines conditions, elles permettent à un attaquant non authentifié d'exécuter du code sur le serveur web. Ces failles étant inhérentes à PHP lui-même, et non au noyau, aux thèmes ou aux extensions WordPress, le correctif doit impérativement provenir d'une version patchée de PHP installée sur le serveur.

Action recommandée : Demandez à votre hébergeur de confirmer que la version PHP utilisée par votre site est corrigée contre les deux vulnérabilités. Si vous administrez vous-même le serveur, installez un package PHP corrigé et redémarrez PHP.

Les avis de sécurité du projet PHP les désignent comme des vulnérabilités d'exécution de code à distance (RCE) via une corruption de mémoire insuffisante (OOM) (CVE-2026-109618) et via un état global obsolète (CVE-2026-109619). Dans les deux cas, une requête qui échoue au mauvais moment peut rendre des données internes invalides, données que PHP utilisera ultérieurement.

Une attaque réussie exécute du code avec les privilèges du compte sous lequel PHP est exécuté. Selon la configuration du serveur, cela pourrait permettre à un attaquant de lire wp-config.php et les identifiants de base de données qu'il contient, d'accéder à la base de données ou de la modifier, ou encore de modifier les fichiers et le contenu du site. Un processus PHP compromis ne donne pas automatiquement à l'attaquant un accès root au serveur.

État d'exploitation (au 21 octobre 2026)

La PHP Foundation a déclaré que son équipe de sécurité n'avait pas trouvé d'exploit fonctionnel dans le code de preuve de concept (PoC) publié avant la sortie officielle, mais que le développement des PoC s'était accéléré. Le 21 octobre, Cloudflare, qui désigne ces vulnérabilités sous le nom de « php2shell », a signalé avoir observé du trafic d'attaque ciblant ses clients et que les attaquants modifiaient leurs charges utiles pour tenter de contourner ses protections. Aucune des deux sources ne fait état d'une compromission réussie confirmée. Le trafic d'attaque indique que les attaquants sont actifs, mais ne confirme pas à lui seul qu'un site a été compromis. Cette section sera mise à jour en fonction de l'évolution de la situation.

Qui est potentiellement concerné ?

Tout site web utilisant une version PHP non corrigée est potentiellement concerné, quelles que soient les versions de WordPress, des thèmes et des extensions utilisées. L'avis de sécurité du projet PHP concerne toutes les installations PHP traitant des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Le projet PHP considère que le risque est le plus élevé pour mod_php, car une faille de sécurité a été mise en évidence : une requête non authentifiée peut la déclencher avant même l’exécution du code applicatif. Cela ne signifie pas pour autant que les autres configurations sont sûres. Toute installation PHP traitant des requêtes web nécessite ce correctif.

Comment vérifier votre version de PHP et l'état des correctifs ?

Dans le tableau de bord WordPress, accédez à Outils → Santé du site → Informations et développez la section Serveur . Vous y trouverez la version de PHP et l'API serveur (SAPI) utilisée par votre site. La plupart des panneaux de contrôle d'hébergement affichent les mêmes informations. Si vous utilisez WP Cerber, vous pouvez également consulter la version de PHP et l'API serveur via WP Cerber → Outils → Diagnostic .

Les correctifs sont inclus dans les versions amont suivantes du projet PHP :

Branche PHP	Version corrigée en amont
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0	Aucune version corrigée disponible en amont. Consultez votre fournisseur pour obtenir une version corrigée ou effectuez une mise à jour.
7.4	Aucune version officielle. Des versions corrigées par le fournisseur existent, par exemple Ubuntu 20.04 LTS avec Ubuntu Pro (7.4.3-4ubuntu2.29+esm5) et, sur les systèmes utilisant déjà le dépôt Remi, Remi 7.4.33-31 (RHEL 8, 9, 10 et versions compatibles). Consultez votre fournisseur ou effectuez une mise à niveau.

Important : il s’agit des versions amont, et non d’un test universel de version minimale. Les distributions Linux et les fournisseurs de solutions LTS (Long Term Support) peuvent intégrer les correctifs dans des versions antérieures, notamment celles des branches 8.2, 8.3 et 8.4 prises en charge. Par exemple, Ubuntu 24.04 LTS conserve ses paquets PHP 8.3 sous une chaîne de version basée sur 8.3.6 et inclut les deux correctifs dans le paquet 8.3.6-0ubuntu0.24.04.13. L’outil Site Health ne permet pas, à lui seul, de déterminer si une version fournie par un fournisseur contient les deux correctifs. Consultez l’avis de sécurité ou le journal des modifications du paquet du fournisseur, ou contactez votre hébergeur. Ne changez pas de dépôt de paquets PHP tiers simplement parce que votre version est inférieure à la version corrigée amont.

PHP 7.4, 8.0 et 8.1. Les versions corrigées de ces branches, basées sur les rétroportages du code source de PHP, corrigent les deux vulnérabilités avec une atténuation minimale pour les versions en fin de vie. Cette atténuation est plus limitée que le correctif complet fourni à partir de la version 8.2. Un processus PHP à court de mémoire est immédiatement arrêté ; un site dépassant sa limite de mémoire peut donc afficher une erreur serveur générique au lieu de l’écran d’erreur critique de WordPress. Sur ces versions, l’outil de suivi de l’état du site peut afficher le même numéro de version avant et après la mise à jour. Il est donc conseillé de vérifier la correction auprès de votre hébergeur ou dans le journal des modifications du paquet. La mise à niveau vers une branche prise en charge reste recommandée.

Le support de PHP 8.2 prendra bientôt fin. Le support de sécurité du projet PHP pour PHP 8.2 s'arrêtera le 31 décembre 2026. Si vous effectuez une mise à niveau depuis PHP 7.4, 8.0 ou 8.1, choisissez PHP 8.3 ou une version ultérieure, sauvegardez votre site au préalable et vérifiez la compatibilité de votre thème et de vos extensions. Vous pouvez également demander à votre hébergeur une version corrigée de votre branche actuelle.

Pourquoi la correction doit-elle être appliquée sur le serveur ?

Le code vulnérable fait partie de l'environnement d'exécution PHP qui exécute WordPress, et non de WordPress lui-même.

La mise à jour de WordPress ne corrige pas ces vulnérabilités PHP. La mise à jour du noyau WordPress, des thèmes ou des extensions ne modifie pas l'environnement d'exécution PHP.

Les extensions de sécurité ne peuvent pas corriger les failles d'exécution. Certaines vulnérabilités peuvent s'exécuter avant même le chargement de WordPress, empêchant ainsi toute analyse de la requête par une extension. Les règles du pare-feu applicatif web (WAF) au niveau de l'hébergement ou du réseau peuvent réduire certaines failles, mais ne remplacent pas entièrement les correctifs de sécurité.

Les modifications apportées aux paramètres directement sur le site ne constituent pas une solution fiable. L'avis du projet PHP met en garde contre l'utilisation de la ini_set() ou des fichiers ` .user.ini de FPM pour appliquer ses mesures de sécurité, et il en va de même pour les paramètres PHP modifiés dans wp-config.php ou par une extension. Même les mesures au niveau du serveur décrites dans l'avis ne font que réduire l'exposition à des vecteurs d'attaque spécifiques et ne sécurisent pas une installation.

Note aux utilisateurs de WP Cerber : WP Cerber s’exécute au sein de WordPress. Il ne peut ni corriger PHP, ni inspecter une requête exploitant une de ces vulnérabilités avant le chargement de WordPress. Pour la même raison, les journaux de WP Cerber peuvent ne pas enregistrer une telle tentative ; par conséquent, l’absence d’entrées suspectes dans les journaux ne prouve pas que le site n’a pas été ciblé. WP Cerber protège WordPress au niveau applicatif, mais ne remplace pas la mise à jour de PHP.

Que faire maintenant

Si vous ne gérez pas le serveur

Cela concerne l'hébergement mutualisé et géré, où votre fournisseur est responsable de la maintenance de l'environnement d'exécution PHP. Demandez-lui de confirmer que la version PHP utilisée par votre site web inclut des correctifs pour les deux vulnérabilités. Vous pouvez lui envoyer cette question telle quelle :

La version PHP qui héberge mon site web est-elle corrigée contre les vulnérabilités CVE-2026-109618 et CVE-2026-109619 ? Les processus PHP concernés ont-ils été redémarrés pour charger la version corrigée ?

Si vous gérez un serveur VPS ou dédié

Mettez à jour PHP. Installez la version corrigée en amont, ou un paquet de distribution ou de fournisseur dont l'avis de mise à jour ou le journal des modifications confirme qu'il contient les deux correctifs.

Redémarrez PHP. Redémarrez ou rechargez PHP-FPM, Apache ou tout autre service exécutant PHP pour vos sites. Les processus en cours d'exécution continuent d'utiliser l'ancien binaire jusqu'à leur redémarrage.

Vérifiez. Consultez l'outil Site Health pour vous assurer que la version PHP attendue est bien utilisée pour chaque site. Ensuite, confirmez séparément, dans les avis de sécurité du fournisseur ou le journal des modifications du paquet, que le paquet installé contient les deux correctifs. Site Health affiche la version en cours d'exécution, mais ne peut pas garantir l'inclusion d'un correctif rétroporté. La commande php -v peut indiquer une installation PHP différente de celle utilisée par votre site web ; ne vous y fiez donc pas uniquement.

Quel que soit votre cas, conservez une sauvegarde récente que vous pouvez restaurer. Si vous soupçonnez que le site a été compromis avant la mise à jour de PHP, sachez que cette mise à jour ne supprime pas les logiciels malveillants ni les portes dérobées. Dans ce cas, contactez d'abord votre hébergeur, car l'accès obtenu via PHP peut ne pas se limiter aux fichiers WordPress. Pour nettoyer votre installation WordPress, consultez notre guide « Que faire si votre site WordPress a été piraté ? » .

Foire aux questions

Mon ordinateur ou mon navigateur est-il à risque lorsque je visite un site web affecté ?

Pas directement. Les vulnérabilités se situent dans le code PHP du serveur web, et non dans les appareils ou navigateurs des visiteurs. Un site compromis par ces failles pourrait toutefois être modifié pour diffuser du contenu malveillant, exposant ainsi les visiteurs à des risques indirects.

Dois-je réinstaller WordPress ?

Non, cela ne permet pas de corriger ces vulnérabilités. Elles sont résolues par la mise à jour de PHP sur le serveur, et la réinstallation de WordPress ne modifie pas PHP. Une réinstallation peut toutefois s'avérer nécessaire pour nettoyer un site compromis.

Puis-je résoudre ce problème sans l'aide de mon hébergeur ?

Cela dépend si vous contrôlez l'environnement d'exécution PHP. Sur un VPS ou un serveur dédié, vous pouvez installer vous-même les paquets corrigés. Sur un hébergement mutualisé ou géré, c'est l'hébergeur qui gère PHP. De nombreux panneaux de contrôle permettent de changer de version de PHP pour un site, mais la présence des correctifs dépend toujours de l'hébergeur.