Le 21 octobre 2026, l’équipe PHP a publié les correctifs de deux failles critiques, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. L’attaquant n’a besoin ni d’identifiant ni de mot de passe. Une seule requête forgée envoyée à votre site peut lui permettre d’exécuter son propre code sur le serveur et de prendre la main sur le site. Quelques heures après la publication, la société de sécurité watchTowr signalait des tentatives d’exploitation des deux failles, et Cloudflare indiquait observer les premières attaques.
Si votre site, votre boutique en ligne ou votre interface d’administration tourne sous PHP, votre serveur doit passer à la version corrigée de PHP dès aujourd’hui.
Ce qui s’est passé
L’équipe PHP a annoncé une version critique le 20 octobre, puis publié les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre à 14:00 UTC. Elle leur attribue un score de 9,2 sur 10 en CVSS v4.0, soit le niveau critique. La première faille concerne la façon dont PHP gère un manque de mémoire. La seconde laisse fuiter des données d’une requête vers la requête suivante traitée par le même processus du serveur.
Tous les modes d’exécution de PHP sur un serveur web sont concernés : PHP-FPM, Apache avec mod_php, php-cgi, LiteSpeed et FrankenPHP. L’équipe PHP considère Apache avec mod_php comme le cas le plus risqué. Son avis de sécurité décrit un exploit démontré où une requête sans authentification déclenche l’attaque avant même que le code du site ne s’exécute.
Au soir du 21 octobre, aucune société de sécurité n’avait signalé d’intrusion confirmée. Du code présenté comme un exploit de ces failles circule déjà en ligne, et des attaques massives peuvent démarrer à tout moment.
Êtes-vous concerné ?
Vérifiez les points suivants. Un seul « oui » suffit.
- Votre site tourne sous WordPress, WooCommerce, Laravel, OpenCart, Bitrix, Drupal, Magento ou un autre système en PHP.
- Votre entreprise a une interface d’administration, un portail client ou une API écrits en PHP. Le backend d’une application mobile compte aussi.
- Votre hébergeur ou votre développeur ne vous a pas confirmé que PHP est déjà à jour sur votre serveur.
- Votre serveur utilise un panneau d’hébergement comme aaPanel. Certains panneaux ne proposaient pas encore de PHP à jour le jour de la publication.
- Votre version de PHP est 8.1 ou antérieure.
Si vous ne connaissez pas les réponses, c’est justement une raison de poser la question aujourd’hui.
Ce qu’un attaquant peut faire de votre site
Exécuter du code sur le serveur donne à l’attaquant les mêmes accès que votre site. Concrètement :
- le contrôle total du site : modifier des pages, créer des comptes administrateur, rediriger vos visiteurs ;
- l’accès à la base de données : noms, e-mails, adresses et commandes de vos clients ;
- des logiciels malveillants ou des pages de spam installés sur votre site ;
- un avertissement de Google dans les résultats de recherche et dans le navigateur, qui coupe le trafic et les ventes jusqu’au nettoyage.
Nettoyer un site compromis peut prendre des jours, et parfois exiger une reconstruction complète. Une mise à jour prend quelques heures.
Ce qu’il faut faire aujourd’hui
1. Trouvez votre version de PHP. Votre panneau d’hébergement l’affiche, en général dans « Version PHP » ou « Paramètres PHP ». Dans WordPress, ouvrez Outils → Santé du site → Infos → Serveur. Sous Ubuntu, le numéro peut rester ancien, par exemple 8.3.6, même après une mise à jour de sécurité, car Ubuntu corrige le paquet sans changer le numéro. Votre hébergeur ou votre développeur doit alors vérifier la version du paquet.
2. Demandez à votre hébergeur ou à votre développeur de mettre PHP à jour. Vous pouvez envoyer ce message tel quel :
Bonjour, le 21 octobre 2026, PHP a publié des correctifs pour les failles critiques CVE-2026-109618 et CVE-2026-109619 (PHP2Shell). Pouvez-vous nous confirmer que PHP sur notre serveur est passé à une version corrigée (8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un paquet corrigé de la distribution) et que PHP-FPM ou Apache a bien été redémarré ? Si nous sommes en PHP 8.1 ou antérieur, merci de nous indiquer comment vous comptez appliquer le correctif. Merci aussi de vérifier les journaux du serveur à la recherche de signes d’exploitation depuis le 21 octobre.
3. Si vous êtes en PHP 8.1 ou antérieur, prévoyez le passage à une version supportée. Pour les versions 7.4, 8.0 et 8.1, l’équipe PHP n’a publié que des correctifs sous forme de code source. Il faut soit compiler PHP depuis les sources avec ces correctifs, soit migrer le site vers une version plus récente.
Désactiver session.upload_progress.enabled dans les paramètres PHP ferme une partie du chemin d’attaque. L’équipe PHP précise que cela ne suffit pas à sécuriser un serveur. Voyez-le comme une solution d’attente jusqu’à la mise à jour.
Votre version et ce qu’il faut faire
| Votre version de PHP | Ce qu’il faut faire |
|---|---|
| 8.5 | Mettre à jour vers 8.5.12 |
| 8.4 | Mettre à jour vers 8.4.27 |
| 8.3 | Mettre à jour vers 8.3.36 |
| 8.2 | Mettre à jour vers 8.2.35. Le support de 8.2 se termine le 31 décembre 2026, prévoyez donc la prochaine montée de version |
| 8.1, 8.0, 7.4 | Pas de mise à jour officielle. Compiler PHP avec les correctifs source ou passer à une version supportée |
| 7.3 et antérieures | Aucun correctif de l’équipe PHP. Passer à une version supportée |
Ubuntu a déjà publié des paquets corrigés. Pour les autres distributions Linux, consultez l’avis de sécurité de votre éditeur.
Comment nous l’avons géré pour nos clients
L’équipe PHP a publié les correctifs à 14:00 UTC. Nos ingénieurs se sont mis au travail environ une heure plus tard. Deux heures après, vers 17:00 UTC, tous les serveurs que nous maintenons étaient protégés : 88 projets dont nous assurons le support.
Sur chaque serveur, nous avons d’abord désactivé le mécanisme vulnérable, puis installé le PHP corrigé. Les panneaux d’hébergement comme aaPanel n’avaient pas de PHP à jour le jour de la publication, nous avons donc compilé PHP depuis les sources avec les correctifs. Nous avons fait de même pour les projets en PHP 7.4, 8.0 et 8.1, que l’équipe PHP ne met plus à jour. Après la mise à jour, nous avons passé en revue les journaux des serveurs pour repérer d’éventuels signes d’exploitation de la faille. Nous n’en avons trouvé aucun.
Notre supervision automatique tourne en continu, et nos ingénieurs interviennent dès qu’elle signale un incident.
Comment nous avons procédé, étape par étape : comment nous avons corrigé 88 projets PHP en trois heures.
Vous n’êtes pas sûr que votre site soit protégé ?
Nous vérifions votre version de PHP et la mettons à jour en un jour ouvré. Si votre site tourne en PHP 8.1 ou antérieur, nous vous dirons quelle option est la plus rapide et la moins coûteuse dans votre cas : une version compilée avec les correctifs ou une montée de version.
Si vous souhaitez ensuite un suivi régulier, voyez notre maintenance de sites et notre maintenance de serveurs. Pour les boutiques WordPress et WooCommerce, nous avons une page dédiée. Si vous soupçonnez une intrusion avant la mise à jour, ou si vous voulez savoir ce qui reste ouvert, un test d’intrusion vous répond.
FAQ
Dois-je mettre à jour si mon site tourne sous WordPress ?
Oui. WordPress fonctionne avec PHP, et la faille se trouve dans PHP lui-même. Mettre à jour WordPress et ses extensions ne la corrige pas. Votre serveur a besoin de la version corrigée de PHP.
Mon hébergeur va-t-il mettre PHP à jour automatiquement ?
Certains le font, d’autres attendent, et sur beaucoup de VPS et de serveurs dédiés personne ne met PHP à jour si vous ne le demandez pas. Demandez à votre hébergeur une confirmation écrite avec la version exacte.
Mon site va-t-il casser après la mise à jour ?
Une mise à jour dans la même branche, par exemple de 8.3.x vers 8.3.36, ne contient que des correctifs de sécurité et de bugs et affecte rarement un site. Passer de 7.4 ou 8.1 à une branche plus récente peut casser d’anciennes extensions ou du vieux code, ce changement doit donc être testé avant.
Désactiver session.upload_progress suffit-il ?
Non. Cela ferme une partie d’un chemin d’attaque. Selon l’équipe PHP, seule la mise à jour règle le problème.
Sources
- Annonce de l’équipe PHP : https://www.php.net/archive/2026.php
- Avis de sécurité : https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w et https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
- Ubuntu : https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
- Tentatives d’attaque et code d’exploitation : https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote