Faille PHP critique « php2shell » : pourquoi mettre à jour PHP maintenant, même sur un WordPress à jour

Ce que l'équipe PHP a annoncé le 21 octobre 2026

Le mardi 20 octobre au soir, l'équipe de sécurité de PHP a prévenu qu'une version critique sortirait le lendemain. Elle a été publiée le mercredi 21 octobre 2026 à 14 h UTC, soit 16 h à Paris. L'annonce officielle est sans ambiguïté : les nouvelles versions « corrigent deux vulnérabilités critiques qui peuvent permettre l'exécution de code à distance sans authentification », et tous les utilisateurs de PHP sont invités à mettre à jour immédiatement.

PHP n'est ni une extension ni un thème. C'est le langage dans lequel WordPress est écrit, et le programme qui, sur le serveur, fabrique chaque page de votre site à chaque visite. Un défaut à ce niveau touche tous les sites qui reposent sur PHP, quel que soit leur contenu : WordPress, WooCommerce, PrestaShop, Joomla, Drupal ou une application développée sur mesure.

PHP	Version corrigée	Situation
8.5	8.5.12	Branche maintenue
8.4	8.4.27	Branche maintenue
8.3	8.3.36	Branche maintenue
8.2	8.2.35	Maintenue jusqu'au 31 décembre 2026
8.1, 8.0 et 7.4	Aucune version officielle	Correctifs minimaux en code source, pour ceux qui compilent PHP eux-mêmes
7.3 et plus ancien	Aucune	Aucun correctif : changer de version est obligatoire

Pour les branches les plus anciennes, l'équipe PHP renvoie vers les distributions Linux et les éditeurs de support long terme, dont certains publient leurs propres correctifs. Pour un site WordPress, la seule réponse durable reste de passer sur une branche maintenue.

Deux failles qui donnent la main sur le serveur

Les deux défauts touchent la façon dont PHP range et nettoie sa mémoire d'une visite à l'autre. Sans entrer dans le code :

• CVE-2026-109618, exécution de code par corruption de la mémoire. Quand une requête épuise la mémoire allouée à PHP au mauvais moment, PHP peut garder des données à moitié préparées, puis les traiter comme valides au moment du nettoyage. Un attaquant qui provoque volontairement ce manque de mémoire, par exemple avec un envoi de formulaire fabriqué pour l'occasion, peut aller jusqu'à faire exécuter son propre code.
• CVE-2026-109619, exécution de code par un état résiduel. Après certaines erreurs fatales, PHP peut conserver une référence vers une zone de mémoire déjà libérée. La requête suivante traitée par le même processus réutilise alors cette zone. Là encore, plusieurs techniques mènent à l'exécution de code.

L'exécution de code à distance est le pire résultat possible pour un site. L'attaquant n'a pas besoin de deviner un mot de passe ni de trouver une extension vulnérable : il envoie des requêtes à votre site et finit par lui faire exécuter ses commandes, avec les droits du serveur web. À partir de là, il peut lire le fichier wp-config.php et le mot de passe de la base de données, créer un compte administrateur, déposer une porte dérobée, injecter des redirections ou des pages de spam, ou utiliser le serveur pour envoyer des emails frauduleux.

Tous les modes de fonctionnement de PHP sont touchés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, autrement dit la quasi-totalité des hébergements. L'équipe PHP juge le risque le plus élevé avec mod_php, encore courant sur les hébergements Apache : une démonstration y déclenche l'attaque avec une seule requête, avant même que WordPress ne démarre. D'après Tenable, le code en cause remonte à PHP 5.4, sorti en 2012.

Pourquoi un WordPress à jour peut rester exposé

C'est le point le plus mal compris, et celui qui distingue cette alerte des failles d'extensions dont nous parlons chaque semaine. Le tableau de bord WordPress peut afficher que tout est à jour alors que le site reste vulnérable. WordPress, ses thèmes et ses extensions tournent au-dessus de PHP, et le bouton de mise à jour de l'administration ne touche jamais au PHP du serveur.

Qui met PHP à jour dépend de votre hébergement :

• Hébergement mutualisé (o2switch, OVHcloud, Hostinger, IONOS et les autres) : c'est l'hébergeur qui installe les versions corrigées sur ses serveurs. Dans votre espace client, vous choisissez seulement la branche, 8.2, 8.3 ou 8.4.
• Serveur dédié ou VPS : c'est vous, ou le prestataire qui administre la machine. Personne d'autre ne le fera à votre place.
• Agence ou freelance sans accès au serveur : il peut mettre à jour WordPress, mais pas PHP. Il doit le demander à l'hébergeur, puis vérifier que c'est fait.

La vraie question pour un dirigeant est donc simple : qui, chez vous, est responsable des mises à jour du serveur, et a-t-il traité celle-ci ? Si la réponse ne vient pas tout de suite, c'est sans doute que personne ne s'en occupe.

Pourquoi il faut agir aujourd'hui

Plusieurs éléments rendent cette faille plus urgente que la moyenne.

• Elle a fuité avant le correctif. Les deux identifiants circulaient dès le 20 octobre, avec une note erronée de 10, et l'un des laboratoires à l'origine de la découverte a publié par erreur une vidéo montrant son attaque à l'œuvre sur plusieurs cibles. La PHP Foundation le reconnaît dans son bilan du 21 octobre.
• Des attaques sont déjà observées. Le réseau de serveurs pièges d'Amazon a enregistré une tentative d'exploitation le 17 octobre, quatre jours avant la publication. Cloudflare signale du trafic d'attaque visant ces failles, et Patchstack des cas d'exploitation remontés par des hébergeurs.
• Un code d'attaque public est attendu. Rapid7 indique que les travaux sont reproduits de façon indépendante et qu'un exploit fonctionnel devrait être rendu public sous peu. À partir de là, les robots qui scannent le Web en permanence l'ajouteront à leur arsenal, et l'attaque deviendra automatique.
• Les autorités sont formelles. L'agence américaine de cybersécurité, la CISA, demande de corriger immédiatement, en commençant par les serveurs exposés à Internet, et de mettre hors ligne les systèmes qui ne peuvent pas l'être. Le NCSC britannique recommande lui aussi d'envisager la mise hors ligne des systèmes impossibles à corriger rapidement.

Pour une entreprise, un site compromis par ce biais se traduit comme un piratage classique, sans avoir commis la moindre erreur : redirections vers des sites frauduleux, pages de spam indexées dans Google, avertissement rouge dans les navigateurs, puis suspension du compte par l'hébergeur si le serveur se met à envoyer du spam. Le nettoyage coûte toujours plus cher que la mise à jour.

Comment vérifier la version de PHP de votre site

Dans WordPress, la version de PHP s'affiche sans rien installer :

1. Ouvrez le menu Outils, puis Santé du site.
2. Cliquez sur l'onglet Infos.
3. Dépliez la section Serveur et lisez la ligne Version de PHP.

Comparez avec le tableau ci-dessus. Si vous lisez 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou un numéro plus élevé dans la même branche, le correctif est en place. Un numéro inférieur, par exemple 8.3.31, signale un site probablement exposé.

Si votre site tourne encore en PHP 8.1, 8.0, 7.4 ou plus ancien, aucune version officielle ne le corrigera. C'est le moment de passer sur une branche maintenue, en vérifiant d'abord la compatibilité du thème et des extensions, ou de changer d'hébergement si votre hébergeur ne propose pas de version récente.

Si la mise à jour ne peut pas être faite tout de suite

Seule la mise à jour corrige réellement les deux failles. L'équipe PHP publie toutefois des mesures qui réduisent l'exposition en attendant. Elles s'adressent aux personnes qui administrent le serveur, pas aux clients d'un hébergement mutualisé :

• Désactiver le suivi de progression des envois avec session.upload_progress.enabled=0, dans le php.ini ou la configuration du pool PHP-FPM, puis redémarrer tous les processus PHP. Placé dans un fichier .user.ini ou appliqué par ini_set(), ce réglage arrive trop tard et ne protège pas.
• Imposer memory_limit=-1 au niveau de l'administration, par exemple avec php_admin_value, pour que les applications ne puissent pas le modifier, et confier la limite de mémoire au système (conteneur ou cgroup).
• Réduire post_max_size à 8 Mo sur les sites sans envoi de fichiers, 32 Mo sinon, et limiter la taille des requêtes au niveau du serveur web.
• Sur PHP 8.5, passer fatal_error_backtraces=0.

Côté propriétaires de sites, une protection existe sans toucher au serveur : Cloudflare indique avoir déployé des règles de pare-feu contre les vecteurs d'attaque connus, pour tous ses clients, y compris en offre gratuite, à condition que le site passe bien par son proxy. Elles ne remplacent pas le correctif, mais réduisent le risque pendant le temps nécessaire à l'hébergeur.

Enfin, les premières tentatives datent du 17 octobre. Sur un site resté sur une version vulnérable, quelques contrôles s'imposent après la mise à jour : la liste des comptes administrateurs, car un administrateur inconnu est le signe le plus fréquent, la présence de fichiers PHP dans wp-content/uploads, qu'il vaut mieux empêcher de s'exécuter, et les journaux du serveur, à la recherche de processus PHP qui lancent des commandes système. Notre analyseur de site repère les signes visibles de l'extérieur. En cas de doute, une intervention de nettoyage à prix fixe vaut mieux qu'une porte dérobée qui attend son heure.

Nos clients sont déjà protégés : c'est le rôle de la maintenance

Tous les sites de nos clients sont déjà passés sur une version corrigée de PHP. Sur les serveurs que nous administrons, la mise à jour a été installée, PHP redémarré et chaque site contrôlé ensuite. Les sites hébergés ailleurs sont eux aussi sur une version corrigée. Nos clients n'ont rien eu à faire, ni même à se renseigner sur la faille.

C'est exactement à cela que sert une maintenance. Une alerte comme celle-ci est annoncée un mardi soir pour le lendemain après-midi. Chez un client suivi, elle est repérée, appliquée et contrôlée sans qu'il ait à s'en occuper. Sur un site sans suivi, elle reste ouverte tant que personne n'y pense, c'est-à-dire souvent jusqu'au jour où le site est piraté.

Si vous ne savez pas qui s'occupe du PHP de votre site, ou si votre hébergeur tarde à répondre, c'est le bon moment pour comparer nos formules ou nous écrire. Pour suivre les autres alertes de l'automne, notre article sur WordPress 7.1.1 récapitule les quatre mises à jour de sécurité du cœur depuis juillet.

Sources

• php.net, « Security advisory: Critical remote code execution vulnerabilities, update now », 21 octobre 2026, php.net
• The PHP Foundation, « Today's PHP Security Release, and How We're Strengthening PHP Security », 21 octobre 2026, thephp.foundation
• CVE Program, fiches CVE-2026-109618 et CVE-2026-109619 (éditeur : PHP Group, CVSS 4.0 : 9,2)
• CISA, « Critical Vulnerabilities in PHP Require Immediate Patching », 21 octobre 2026, cisa.gov
• Rapid7, « CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated Remote Code Execution in PHP », 21 octobre 2026, rapid7.com
• Tenable, « php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions », octobre 2026, tenable.com
• Help Net Security, « PHP2Shell: Critical PHP vulnerabilities patched, update now! », 21 octobre 2026, mis à jour le 22 octobre, helpnetsecurity.com
• Qualys, « PHP2Shell: PHP Patches Two Critical RCE Vulnerabilities, Urges Immediate Updates », octobre 2026, qualys.com