Le 20 octobre 2026, l’équipe de sécurité de PHP a fait quelque chose qu’elle ne fait presque jamais : annoncer une sortie à l’avance. Deux failles critiques, notées 9,2 sur 10, avec un correctif annoncé pour le lendemain à 14 h UTC et une consigne claire — préparez-vous dès maintenant. Le correctif est sorti à l’heure dite, le 21 octobre. Nos serveurs ont été mis à jour le jour même.
De quoi s’agit-il
Deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, que les chercheurs ont surnommées « php2shell ». Les deux permettent à un visiteur non authentifié — c’est-à-dire n’importe qui — de faire exécuter du code au serveur.
- CVE-2026-109618 : la gestion du dépassement de la limite de mémoire peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées. Le nettoyage de fin de requête traite ensuite ces données invalides comme si elles étaient valides.
- CVE-2026-109619 : un état interne appartenant à une requête peut survivre à la libération de la mémoire qui le portait. Une requête suivante, traitée par le même processus, peut alors utiliser cet état périmé avant que l’initialisation normale le remette à zéro.
L’avis officiel précise que toutes les façons de servir du PHP sont touchées — PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed — et que le risque est le plus élevé avec mod_php, où les chercheurs ont démontré qu’une seule requête non authentifiée suffit à déclencher l’attaque avant même que le code du site s’exécute.
Pourquoi celle-ci n’est pas comme les autres
D’habitude, quand nous publions ce genre d’avis, la faille se trouve dans WordPress, dans un thème ou dans une extension. Le correctif appartient alors au propriétaire du site.
Cette fois, la faille est dans PHP lui-même, le moteur qui exécute le site. Aucune version de WordPress, aucun thème et aucune extension ne protège contre elle. Un site vitrine de trois pages est exposé au même titre qu’une boutique WooCommerce, et un site parfaitement à jour l’est autant qu’un site négligé.
La contrepartie est plus agréable à écrire : le correctif se pose au niveau du serveur. C’est notre travail, pas le vôtre.
Ce que nous avons fait
Le préavis du 20 octobre nous a permis d’être prêts : la fenêtre de déploiement était planifiée avant même que les correctifs existent. Dès que les paquets corrigés ont été publiés, ils ont été déployés sur l’ensemble de nos serveurs, puis les processus PHP ont été redémarrés — sans ce redémarrage, les processus déjà en mémoire continueraient de servir le code vulnérable, et la mise à jour ne servirait à rien.
Les versions corrigées
PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures ne sont plus suivies par le projet PHP, mais devant la gravité du problème, l’équipe de sécurité a tout de même produit des correctifs minimaux pour 7.4, 8.0 et 8.1, à l’intention de ceux qui compilent PHP eux-mêmes.
De notre côté, cPanel a publié des paquets corrigés pour les branches 8.2 à 8.5, ainsi que des rétroportages pour 8.1, 8.0, 7.4 et 7.2. Autrement dit, la quasi-totalité des sites hébergés chez nous sont couverts, y compris ceux qui tournent sur des versions de PHP abandonnées depuis des années.
Il y a une exception : PHP 7.3. Au moment d’écrire ces lignes, aucun correctif n’existe pour cette branche, ni du côté de PHP, ni du côté de cPanel. Un site qui tourne en PHP 7.3 reste vulnérable, et le seul remède est de changer de version.
Ce que vous devriez faire
Pour la grande majorité de nos clients : rien. Le correctif a été appliqué sous votre site, sans intervention de votre part et sans interruption de service.
Si votre site tourne en PHP 7.3, c’est différent, et c’est à régler sans attendre. Vous pouvez voir et changer la version de PHP depuis votre cPanel, dans « Sélectionner la version de PHP ». Si vous n’êtes pas certain de la version utilisée par votre site, ou si vous préférez que nous fassions le changement, ouvrez-nous un billet et nous nous en occupons.
Une mise en garde, par contre : passer de PHP 7.3 à une version récente n’est pas toujours sans conséquence. Un thème ou une extension trop ancienne peut cesser de fonctionner. Avant de changer, mettez à jour WordPress, le thème et les extensions, et faites une sauvegarde. Si vous travaillez avec une agence web, c’est le moment de l’appeler.
Plus largement : si votre site tourne encore sur une version de PHP 7, cet épisode est un bon rappel. Ces branches ne reçoivent plus de correctifs depuis des années. Celui d’aujourd’hui est une exception accordée à cause de la gravité du problème, pas un retour du support.
Sur l’exploitation, soyons précis
L’information circule vite et mal sur ce dossier, alors autant être exact. Les détails des deux failles ont fuité avant la date d’embargo, et un outil de démonstration appelé PHP2Shell circule depuis. L’entreprise de recherche watchTowr indique avoir reproduit la CVE-2026-109618 par elle-même.
En revanche, au moment d’écrire ces lignes, l’exploitation massive n’est pas confirmée : les observations se contredisent d’un fournisseur à l’autre, et la CISA américaine n’a pas inscrit ces failles à son catalogue des vulnérabilités activement exploitées. Il faut donc lire « exploitation attendue » plutôt que « exploitation en cours ». Cela ne change rien à l’urgence du correctif — c’est justement pour ne pas avoir à trancher cette question qu’on l’applique tout de suite.
On a aussi beaucoup lu que « toutes les versions depuis PHP 5 » seraient touchées. Cette affirmation provient de la fuite et n’est confirmée par aucun avis officiel.
Sources
- L’avis de sécurité officiel de PHP
- Les avis techniques de l’équipe php-src : GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp
- La foire aux questions de Tenable
- L’analyse de watchTowr
Si vous êtes client chez nous et que vous avez des questions sur l’état de votre site, écrivez-nous.