Faille PHP du 21 octobre 2026 (PHP2Shell) : comment mettre à jour PHP sur WordPress

Le 21 octobre 2026, le projet PHP a publié une mise à jour de sécurité critique : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux failles PHP, surnommées PHP2Shell, qui permettent, dans certaines conditions, d'exécuter du code à distance sur un serveur sans s'authentifier. Tous les sites qui tournent en PHP sont concernés, donc la quasi-totalité des sites WordPress, WooCommerce et PrestaShop. La consigne de l'équipe PHP est nette : mettre à jour immédiatement, car aucun réglage ne protège complètement.

État des informations au 21 octobre 2026 au soir. Cet article sera complété au fil des correctifs des hébergeurs.

L'essentiel en 30 secondes

• Deux failles critiques : CVE-2026-109618 et CVE-2026-109619, notées 9,2 en CVSS v4.0, exploitables à distance et sans authentification, dans certaines conditions de configuration.
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Mettre à jour WordPress ne corrige pas cette faille PHP : c'est le moteur PHP du serveur qu'il faut mettre à jour, chez l'hébergeur ou sur votre propre serveur.
• PHP 8.1, 8.0, 7.4 et plus ancien ne reçoivent plus de version officielle : il faut migrer vers une version maintenue.
• PHP 8.2 est corrigé, mais son support de sécurité s'arrête le 31 décembre 2026 : prévoyez dès maintenant le passage à PHP 8.3 ou plus récent.

Que s'est-il passé le 21 octobre 2026 ?

Le 20 octobre, le site officiel php.net a annoncé une mise à jour de sécurité critique pour le lendemain, 14 h UTC, soit 16 h à Paris. D'après la PHP Foundation, les deux numéros de faille circulaient déjà depuis l'après-midi sur des forums et des réseaux sociaux, avec une note erronée de 10 sur 10, mais sans détail technique. Le soir même, une vidéo de démonstration publiée par erreur par l'une des équipes de chercheurs a révélé quelques détails de plus. Le projet PHP a donc avancé la publication, initialement prévue le 22 octobre. Les correctifs ont été publiés le 21 octobre pour les quatre branches encore maintenues. Les distributions Linux et les fournisseurs de support étendu les avaient reçus à l'avance.

Deux failles critiques : CVE-2026-109618 et CVE-2026-109619

CVE-2026-109618, la corruption de mémoire lors d'une saturation. Quand une requête épuise la mémoire allouée à PHP au mauvais moment, PHP peut laisser des données internes à moitié initialisées, puis les traiter comme valides lors du nettoyage de la requête. En provoquant volontairement cette saturation, par exemple avec un envoi de formulaire fabriqué, un attaquant peut corrompre la mémoire et faire exécuter son propre code. Sur Apache avec mod_php, une exécution de code complète a été démontrée avant même que le code du site ne démarre, avec les limites de mémoire et d'envoi par défaut de PHP. Sur PHP-FPM, l'avis technique juge cette faille exploitable en principe, sans attaque complète démontrée à ce jour.

CVE-2026-109619, l'état laissé par une requête précédente. Un processus PHP traite les requêtes les unes après les autres. Si une erreur fatale interrompt une opération au mauvais moment, des informations internes peuvent continuer à pointer vers la mémoire d'une requête déjà terminée. Une requête suivante, traitée par le même processus, peut alors utiliser cette mémoire libérée : c'est une faille de type « use after free ». Elle a permis une exécution de code sur Apache avec mod_php, y compris contre une application réelle, et sur PHP-FPM quand l'application offre un chemin adapté. Elle peut aussi laisser lire des données présentes en mémoire.

Les deux failles touchent la gestion de la mémoire et des erreurs, deux mécanismes que presque toutes les requêtes traversent. C'est ce qui les rend graves, y compris pour les sites servis par PHP-FPM, la configuration la plus courante.

Pourquoi parle-t-on de « PHP2Shell » ?

PHP2Shell est le nom que Calif, l'une des équipes de chercheurs qui ont découvert les failles, a donné à sa démonstration d'attaque. La presse spécialisée l'a repris pour désigner les deux failles. Dans les cas les plus graves, elles permettent d'obtenir un accès en ligne de commande (un « shell ») sur le serveur à partir de requêtes web, avec les droits du compte qui fait tourner PHP. Le nom n'est pas officiel : les références à retenir sont les deux numéros CVE.

Ce que disent l'équipe PHP, le CERT-FR et WordPress

• L'équipe PHP considère comme exposées toutes les installations de PHP qui répondent à des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, le risque étant le plus élevé avec mod_php. Seule la mise à jour est une solution complète.
• Le CERT-FR, l'équipe gouvernementale de réponse aux incidents informatiques rattachée à l'ANSSI, a publié le 21 octobre une alerte (CERTFR-2026-ALE-014) et un avis (CERTFR-2026-AVI-1359). Pour PHP 8.1 et les versions plus anciennes, qui ne sont plus maintenues, il recommande d'isoler les serveurs concernés puis de migrer vers une version maintenue et à jour.
• WordPress rappelle que ces vulnérabilités ne sont pas propres à WordPress : aucune mise à jour de WordPress n'est requise, c'est PHP qu'il faut mettre à jour.

Selon la PHP Foundation, l'équipe de sécurité de PHP n'avait identifié, au moment de la publication, aucun code d'exploitation fonctionnel parmi ceux qui circulaient après la fuite. Mais des démonstrations d'attaque circulaient de plus en plus le 21 octobre, et plusieurs sociétés de sécurité ont signalé des tentatives d'attaque le même jour. Au soir du 21 octobre, aucune intrusion réussie n'avait été détaillée publiquement, et les deux failles ne figuraient pas au catalogue des failles exploitées de l'agence américaine CISA. Les correctifs étant publics, il ne faut pas attendre.

Votre site est-il concerné ? Les versions PHP à installer

Oui, si votre site tourne sous une version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou sous PHP 8.1 ou plus ancien : le CERT-FR considère toutes ces versions comme affectées.

Branche PHP	Version corrigée	Fin du support de sécurité
PHP 8.5	8.5.12	31 décembre 2029
PHP 8.4	8.4.27	31 décembre 2028
PHP 8.3	8.3.36	31 décembre 2027
PHP 8.2	8.2.35	31 décembre 2026
PHP 8.1, 8.0, 7.4 et plus ancien	Aucune version officielle	Support terminé

Source : php.net, versions prises en charge et annonce du 21 octobre 2026.

Attention : certaines distributions Linux (Debian, Ubuntu, Red Hat) corrigent PHP sans changer son numéro de version. Chez elles, un PHP corrigé n'affichera pas forcément 8.3.36 : c'est le bulletin de sécurité de la distribution qui fait foi.

PHP 8.2 : corrigé, mais plus de correctif après le 31 décembre 2026

Les sites en PHP 8.2 doivent installer la 8.2.35 tout de suite, puis préparer leur passage à PHP 8.3 ou plus récent avant la fin de l'année. Après le 31 décembre 2026, une faille découverte dans PHP 8.2 ne sera plus corrigée par le projet PHP.

PHP 8.1, 8.0, 7.4 et plus ancien : plus de version officielle

Ces branches ne reçoivent plus de mise à jour du projet PHP. Vu la gravité des failles, l'équipe PHP a exceptionnellement publié des correctifs minimaux sous forme de code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes. Certaines distributions Linux, certains fournisseurs de support étendu et certains éditeurs comme Plesk proposent aussi des versions corrigées. Pour PHP 7.3 et plus ancien, le projet PHP ne fournit aucun correctif. Ce sont des solutions d'attente : un site en PHP 7.4 reste exposé aux autres failles corrigées depuis la fin de son support, le 28 novembre 2022.

Comment connaître la version PHP de son site WordPress

Depuis WordPress : Outils > Santé du site

Dans l'administration WordPress, ouvrez Outils > Santé du site, onglet Informations, puis la rubrique Serveur : la version de PHP y est affichée.

Depuis l'espace client de l'hébergeur ou Plesk

La plupart des hébergeurs affichent la version de PHP de chaque site dans leur espace client. Sous Plesk, la version de chaque domaine figure dans ses paramètres PHP (Sites Web & Domaines), et les versions installées sur le serveur sont listées dans Outils & Paramètres > Paramètres PHP.

En ligne de commande : pourquoi php -v ne suffit pas toujours

Sur un serveur, la commande php -v donne la version de PHP en ligne de commande. Le site, lui, peut être servi par une autre version, celle de PHP-FPM ou du module Apache choisie pour le domaine. Fiez-vous plutôt à WordPress ou au panneau d'administration.

Comment mettre à jour PHP selon votre hébergement

PHP se met à jour là où il est installé, jamais depuis WordPress : chez l'hébergeur sur un hébergement mutualisé, dans Plesk ou par les paquets du système sur un serveur.

Mise à jour PHP chez OVHcloud et les hébergeurs mutualisés : l'hébergeur a la main

Sur un hébergement mutualisé, c'est l'hébergeur qui installe les versions corrigées de PHP. OVHcloud, par exemple, a appliqué une mesure de contournement sur ses hébergements web le 21 octobre à 8 h UTC (10 h à Paris). D'après sa page de statut, les versions de PHP 7.4 à 8.5 étaient corrigées sur l'ensemble de ses hébergements web le même jour à 17 h 53 UTC, les versions plus anciennes restant en cours de traitement. Pour PHP 7.4, 8.0 et 8.1, la version corrigée garde le même numéro : le numéro affiché ne dit donc pas si le correctif est en place. Votre rôle : vérifier que votre site n'utilise pas une branche abandonnée et, si c'est le cas, choisir une version plus récente dans votre espace client.

Mise à jour PHP sur un serveur Plesk : installer les versions corrigées

Plesk fournit ses propres versions de PHP. D'après son support, les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont disponibles depuis le 21 octobre, ainsi que, sous Linux, des versions 7.4, 8.0 et 8.1 recompilées avec le correctif. Installez-les depuis Outils & Paramètres, rubrique Mises à jour, ou Mises à jour système, où apparaissent les paquets plesk-php. Si l'installation automatique des mises à jour est activée, Plesk les installe aussi pendant sa tâche de nuit. Vérifiez ensuite la version de chaque domaine. Pour 7.4, 8.0 et 8.1, le numéro ne change pas : seule la date de compilation, sur la ligne « built » de la commande php -v de cette version, montre que le correctif est en place. Profitez-en pour repérer les domaines encore en PHP 7.4, 8.0 ou 8.1.

VPS ou serveur dédié Linux : paquets du système et redémarrage de PHP-FPM

Installez les paquets PHP mis à jour fournis par votre distribution ou par le dépôt que vous utilisez, puis redémarrez PHP-FPM, ainsi qu'Apache si PHP y est chargé en module (mod_php) : tant que les anciens processus tournent, l'ancienne version reste en mémoire. Pour PHP 8.1 et plus ancien, vérifiez que votre fournisseur publie bien un paquet corrigé. Si vous n'avez pas la main sur votre serveur au quotidien, c'est le rôle de l'infogérance de serveur.

Changer de version PHP sans casser son site WordPress

1. Sauvegarder les fichiers et la base de données.
2. Mettre à jour WordPress, le thème et les extensions, et repérer celles qui ne sont plus maintenues.
3. Tester si possible sur une copie du site (préproduction) avant de toucher au site en ligne.
4. Changer la version, puis contrôler aussitôt les pages principales, l'administration, les formulaires et le journal d'erreurs.
5. Revenir à la version précédente si le site ne répond plus, le temps de corriger.

Le passage de PHP 7 à PHP 8 n'est pas anodin. Un exemple fréquent : une extension ancienne qui applique la fonction count() à une valeur qui n'est pas une liste, par exemple une variable vide (null). PHP 7.4 se contentait d'un avertissement. PHP 8 déclenche une erreur qui, si l'extension ne la traite pas, devient une erreur fatale : la page affiche « Il y a eu une erreur critique sur ce site », et souvent tout le site si l'extension se charge partout. La correction tient souvent en une ligne, encore faut-il la trouver vite dans les journaux. C'est le métier de nos développeurs WordPress.

En attendant le correctif : les mesures provisoires et leurs limites

Si la mise à jour ne peut pas être faite tout de suite, l'avis de PHP liste des réglages qui ferment certains chemins d'attaque, sans rendre l'installation sûre :

• imposer memory_limit=-1 au niveau de l'administrateur (par exemple php_admin_value dans le pool PHP-FPM), la mesure principale contre la première faille. Elle supprime la limite de mémoire de PHP : une seule requête peut alors occuper toute la mémoire du serveur, il faut donc poser une limite ailleurs, par exemple sur le conteneur ;
• désactiver le suivi de progression des envois (session.upload_progress.enabled=0) dans le php.ini, le pool PHP-FPM ou la configuration du serveur web, puis redémarrer tous les processus. Un fichier .user.ini ou un appel ini_set() ne suffit pas ;
• abaisser la taille maximale des envois (post_max_size à 8 Mo sans envoi de fichiers, 32 Mo sinon) ;
• sur PHP 8.5, désactiver les traces d'erreurs fatales (fatal_error_backtraces=0), puis redémarrer tous les processus ;
• retirer les réglages PHP invalides ou obsolètes appliqués à chaque requête, par exemple les php_value d'un fichier .htaccess. Masquer les messages d'erreur ne protège pas ;
• limiter au niveau du serveur web ou du proxy la taille et la complexité des requêtes.

Ces réglages se font sur le serveur et demandent du soin. Ils ne remplacent pas la mise à jour.

Après la mise à jour : vérifier que le site n'a pas été compromis

Les signes qui doivent alerter

• des redirections vers des sites inconnus, surtout depuis Google ou sur mobile ;
• un compte administrateur que vous n'avez pas créé ;
• des fichiers PHP inconnus, notamment dans le dossier des médias (wp-content/uploads) ;
• un problème signalé dans le rapport « Problèmes de sécurité » de Google Search Console, ou un avertissement de votre hébergeur ;
• une consommation de ressources ou un envoi d'e-mails anormaux.

Comme la seconde faille peut laisser lire des données présentes en mémoire, un serveur resté exposé gagne à changer ses mots de passe et ses clés d'accès sensibles après la mise à jour.

Que faire si le site a été piraté

Mettez le site hors ligne. Gardez une copie du site piraté et des journaux du serveur, utiles pour comprendre l'attaque. Restaurez une sauvegarde saine, antérieure à l'intrusion, puis appliquez toutes les mises à jour (PHP, WordPress, thème, extensions). Changez ensuite tous les mots de passe (WordPress, base de données, FTP, SSH, hébergement) et les clés secrètes du fichier wp-config.php, puis remettez le site en ligne.

Si des données personnelles ont pu être consultées, par exemple les clients d'une boutique WooCommerce, la violation doit être notifiée à la CNIL au plus tard 72 heures après sa découverte, sauf si elle ne présente pas de risque pour les personnes. Les entreprises et les associations peuvent aussi se faire aider par cybermalveillance.gouv.fr. Enfin, si Google a signalé le site, le rapport « Problèmes de sécurité » de la Search Console l'indique : une fois tout corrigé, cliquez sur « Demander un examen » dans ce rapport.

Maintenance de site WordPress : ne plus gérer ces alertes seul

Corriger PHP au plus vite est indispensable, mais la sécurité d'un site WordPress se joue toute l'année : le cœur de WordPress, le thème et chaque extension reçoivent leurs propres correctifs. Un site dont personne ne s'occupe accumule les retards, jusqu'au jour où une mise à jour urgente révèle des extensions incompatibles.

Ce que couvre notre contrat de maintenance WordPress

• Veille de sécurité : nous suivons les alertes de PHP, de WordPress et des extensions installées sur vos sites, et nous traitons les correctifs critiques en priorité.
• Mises à jour testées de PHP, de WordPress, du thème et des extensions. Avant chaque changement de version de PHP, nous sauvegardons le site, nous relevons l'état de ses pages, puis nous comparons après la bascule. En cas de problème, nous corrigeons ou nous revenons à la version précédente.
• Correction des incompatibilités : quand une extension ancienne bloque le passage à PHP 8, nous la corrigeons ou nous la remplaçons. Nous développons des extensions WordPress, nous savons les lire.
• Sauvegardes et remise en route : sauvegardes régulières, restauration, intervention en cas de page blanche ou de piratage.
• Serveur : pour les sites hébergés sur un serveur dédié ou un VPS, nous assurons aussi l'infogérance et les mises à jour de sécurité du serveur (Plesk, Apache, Nginx, MySQL, PHP).

Nos outils repèrent les alertes et les écarts, un développeur décide, applique et vérifie. L'IA propose, l'humain décide : c'est aussi vrai pour la maintenance.

Pour qui, et comment démarrer

Pour les entreprises, les éditeurs de presse, les associations et les collectivités dont le site WordPress ou la boutique WooCommerce doit rester en ligne et à jour. Vous ne savez pas quelle version de PHP fait tourner votre site, ou qui doit faire la mise à jour ? Écrivez-nous : nous vérifions votre site, nous vous disons quoi faire, puis nous pouvons nous en charger.

Questions fréquentes sur la faille PHP

Faille PHP : c'est quoi ?

Ce sont deux vulnérabilités critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell et notées 9,2 en CVSS v4.0. Elles permettent, dans certaines conditions, d'exécuter du code à distance sur un serveur sans s'authentifier. Le projet PHP les a corrigées le 21 octobre 2026.

Faille PHP : que faire ?

Vérifiez la version de PHP de votre site, puis installez la version corrigée de votre branche : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet corrigé de votre distribution Linux, dont le numéro peut être différent. Sur un hébergement mutualisé, c'est l'hébergeur qui met PHP à jour. Avec PHP 8.1 ou plus ancien, il faut migrer vers une version maintenue.

Comment mettre à jour PHP sur WordPress ?

PHP ne se met pas à jour depuis WordPress mais chez l'hébergeur ou sur le serveur : espace client de l'hébergeur, panneau Plesk ou paquets du système. Aucune mise à jour de WordPress n'est nécessaire pour corriger ces deux failles. Faites une sauvegarde avant tout changement de version.

Comment connaître la version PHP de mon site WordPress ?

Dans l'administration WordPress, ouvrez Outils > Santé du site > Informations > Serveur : la version de PHP y est affichée. La plupart des hébergeurs l'indiquent aussi dans leur espace client.

Quelle version de PHP pour WordPress ?

WordPress recommande PHP 8.3 ou plus récent. Choisissez une version à jour d'une branche maintenue : 8.3.36, 8.4.27 ou 8.5.12 à ce jour, en vérifiant que votre version de WordPress, votre thème et vos extensions la prennent en charge. PHP 8.2 est corrigé mais n'aura plus de correctif après le 31 décembre 2026.

Mon hébergement OVH est-il déjà corrigé ?

D'après la page de statut OVHcloud, les versions de PHP 7.4 à 8.5 étaient corrigées sur tous ses hébergements web le 21 octobre 2026 à 17 h 53 UTC, après une mesure de contournement appliquée à 8 h UTC. Les versions plus anciennes étaient encore en cours de traitement : vérifiez la version de votre site dans l'espace client.

Sources

Sources consultées le 21 octobre 2026 au soir.

• php.net, avis de sécurité du 21 octobre 2026 : versions corrigées, systèmes concernés, mesures provisoires.
• php.net, versions prises en charge et versions en fin de vie : dates de fin de support.
• Avis GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et avis GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) : détails techniques et note CVSS v4.0.
• PHP Foundation, 21 octobre 2026 : chronologie, fuite des identifiants, état de l'exploitation.
• CERT-FR, alerte CERTFR-2026-ALE-014 et avis CERTFR-2026-AVI-1359.
• WordPress.org, 21 octobre 2026 et WordPress francophone : position de WordPress. Prérequis de WordPress : versions de PHP recommandées.
• Plesk, article de support : versions corrigées fournies par Plesk.
• OVHcloud, page de statut des hébergements web : contournement et déploiement des correctifs.
• Wikipédia, PHP2Shell : origine du nom.
• Google, rapport sur les problèmes de sécurité : demande d'examen après un piratage.

Pour aller plus loin : toutes nos actualités.