Une alerte de sécurité d’un niveau critique secoue l’écosystème web mondial ce 21 octobre 2026. Plusieurs équipes de recherche en cybersécurité (Wiz, OpenAI, Calif et Quarkslab) ont coordonné la divulgation publique de deux vulnérabilités majeures touchant le cœur du moteur PHP. Identifiées sous les références CVE-2026-109618 et CVE-2026-109619, et regroupées sous le nom de baptême php2shell, ces failles permettent une exécution de code arbitraire à distance (RCE) sans aucune authentification préalable.
Avec un score de sévérité CVSS v4.0 compris entre 9.2 et 10.0, cette crise rappelle la vulnérabilité historique Log4Shell par son caractère universel : elle frappe directement l’interpréteur PHP avant même que votre CMS (PrestaShop, WordPress, Drupal ou framework Symfony/Laravel) ne prenne la main.
Pourquoi vos plugins de sécurité ne vous protègent pas
Le premier réflexe de beaucoup d’administrateurs WordPress ou marchands PrestaShop consiste à vérifier l’état de leur plugin de sécurité : Wordfence, iThemes Security, Sucuri, ou les modules de protection PrestaShop.
Cette réaction repose sur une mauvaise compréhension du cycle de vie d’une requête HTTP en PHP :
- Le serveur web (Nginx, Apache ou LiteSpeed) reçoit la requête POST entrante et la transmet au socket FastCGI.
- Le moteur C de PHP démarre son initialisation et analyse le corps de la requête dans
main/rfc1867.cpour construire les variables superglobales$_POSTet$_FILES. - C’est précisément à cette étape que l’exploit php2shell se déclenche.
- L’interpréteur C est détourné en mémoire avant que le fichier
wp-config.php,wp-settings.phpouconfig/config.inc.phpne soit lu sur le disque.
En clair : lorsque le code de vos plugins ou de vos modules de sécurité démarre, le pirate a déjà obtenu l’exécution de son shellcode au niveau du processus système. Compter sur un plugin applicatif face à php2shell est une illusion technique totale.
Les deux mécanismes de l’attaque en détail
Pour comprendre la dangerosité de php2shell, il faut regarder ce qui se passe dans les rouages du ramasse-miettes et de la gestion mémoire de l’interpréteur C de PHP.
+-------------------------------------------------------------------+
| Flux d'exécution de la requête HTTP |
+-------------------------------------------------------------------+
[ Requête POST multipart malformée ]
│
▼
[ PHP Core C Engine : rfc1867.c ]
- Parsing des flux et frontières multipart
- Dépassement mémoire calculé (OOM Fatal)
│
├─────────────────────────────┐
▼ ▼
[ CVE-2026-109618 ] [ CVE-2026-109619 ]
Avortement longjmp() État résiduel orphelin
Pointeurs non initialisés Worker FPM persistant
Corruption de la heap Use-After-Free (UAF)
│ │
└──────────────┬──────────────┘
▼
[ Hijack RIP / Exécution de shellcode ]1. CVE-2026-109618 : rupture par OOM et déroutement longjmp()
Cette première faille exploite la gestion des requêtes POST de type multipart/form-data. Un attaquant forge une requête comportant des en-têtes de parties multipart anormalement profondes ou cycliques, couplées à une allocation volumineuse conçue pour percuter exactement le plafond de mémoire allouée (memory_limit).
Lorsque PHP atteint ce seuil critique, le moteur C abandonne l’exécution en cours via un saut non local longjmp() direct vers la routine de nettoyage de fin de requête (php_request_shutdown). Le problème réside dans ce nettoyage d’urgence : la routine suppose que toutes les structures internes de suivi de fichiers ont été complètement initialisées. Or, en interrompant le processus en plein vol, certains pointeurs du tas (heap) pointent vers de la mémoire non allouée ou résiduelle. La libération de ces pointeurs corrompt la table des blocs mémoire et permet à un attaquant expérimenté d’écraser l’adresse de retour d’une fonction pour exécuter du code arbitraire.
2. CVE-2026-109619 : persistance de contexte dans les workers PHP-FPM
La seconde vulnérabilité est encore plus redoutable pour les environnements de production utilisant PHP-FPM ou les architectures à processus réutilisables (pools de workers).
Normalement, à chaque fin de requête HTTP, l’environnement global est réinitialisé (php_request_shutdown) pour que le worker FPM traite la requête suivante avec un état vierge. Les chercheurs ont découvert que certaines structures globales allouées lors de transferts multipart tronqués survivaient à la fermeture de la requête et restaient en mémoire vive dans le worker hôte.
En envoyant immédiatement une seconde requête soigneusement calibrée vers le même worker FPM, l’attaquant déclenche une situation de Use-After-Free (utilisation de mémoire après libération). Il peut ainsi manipuler l’agencement du tas pour injecter un payload binaire directement dans le processus en cours d’exécution.
Le scénario noir pour PrestaShop et WordPress : le skimmer en mémoire
Contrairement aux attaques d’il y a dix ans où les pirates défaçaient la page d’accueil d’un site pour afficher une revendication, l’exploitation moderne de failles comme php2shell vise la discrétion absolue et la rentabilité financière.
Sur une boutique PrestaShop ou un site e-commerce WooCommerce, le risque majeur est l’installation d’un Magecart 100 % résident en mémoire :
- Le pirate n’a pas besoin de modifier un fichier
.phpsur votre serveur, ce qui rend les scanners d’intégrité de fichiers totalement aveugles. - Le payload intercepte les requêtes POST au moment du passage en caisse (numéros de carte, dates d’expiration, cryptogrammes CVV) au niveau du worker PHP actif, avant que les données ne soient chiffrées ou expédiées vers les passerelles sécurisées (Stripe, PayPal, Mollie).
- Les données bancaires volées sont exfiltrées en tâche de fond vers des serveurs relais chiffrés.
- Dès que le pool PHP-FPM redémarre, le malware disparaît de la RAM sans laisser d’empreinte sur le disque dur, ne laissant pour seule trace qu’un crash silencieux dans les logs système.
Quelles sont les versions concernées et les correctifs ?
Le groupe de maintenance officiel du projet PHP a déployé en urgence des correctifs pour toutes les branches actuellement maintenues :
| Branche PHP | Version vulnérable | Version corrigée officielle | Statut du support |
|---|---|---|---|
| PHP 8.4 | <= 8.4.26 | 8.4.27 | Actif (Recommandé) |
| PHP 8.3 | <= 8.3.35 | 8.3.36 | Actif |
| PHP 8.2 | <= 8.2.34 | 8.2.35 | Sécurité uniquement |
| PHP 8.1 | Toutes versions | Aucun patch amont | Fin de vie (EOL) |
| PHP 7.4 | Toutes versions | Aucun patch amont | Fin de vie (EOL) |
[!WARNING] Si votre serveur ou votre boutique tourne encore sous PHP 7.4 ou PHP 8.1, aucun correctif officiel ne sera publié par php.net. Vous devez soit compter sur les rétro-portages (backports) de votre distribution Linux (Debian LTS, Ubuntu ESM, dépôts CloudLinux/AlmaLinux), soit planifier une montée de version immédiate vers PHP 8.2+.
Procédure d’urgence pour sécuriser votre serveur
Si vous administrez un serveur dédié, un serveur cloud ou un VPS, suivez ces étapes dès maintenant. Cela ne prend que quelques minutes et élimine immédiatement la menace.
1. Contrôler votre version de PHP en ligne de commande
Connectez-vous en SSH à votre serveur et vérifiez la version exacte de votre binaire CLI ainsi que celle de votre démon FPM :
php -v
php-fpm8.3 -v # Adapter selon votre version installée (8.2, 8.3, 8.4)Si le numéro de sous-version est inférieur à ceux listés dans le tableau ci-dessus, votre machine est vulnérable.
2. Mettre à jour les paquets de votre distribution
Sur Debian / Ubuntu (avec les dépôts officiels ou le PPA d’Ondřej Surý) :
sudo apt update
sudo apt --only-upgrade install php8.3 php8.3-fpm php8.3-cli php8.3-commonSur AlmaLinux / Rocky Linux / RHEL / CentOS Stream (avec les dépôts Remi) :
sudo dnf check-update
sudo dnf upgrade php php-fpm3. Redémarrer obligatoirement le service PHP-FPM
La mise à jour des paquets sur le disque ne suffit pas. Les processus workers actuellement en mémoire continuent d’exécuter l’ancien binaire vulnérable tant qu’ils ne sont pas détruits et réinstanciés :
# Pour Ubuntu / Debian
sudo systemctl restart php8.3-fpm
# Pour AlmaLinux / Rocky Linux
sudo systemctl restart php-fpmVérifiez ensuite que le service a bien redémarré avec la nouvelle version :
sudo systemctl status php8.3-fpm4. Mesure temporaire de mitigation via le reverse proxy
Si vous ne pouvez pas mettre à jour PHP immédiatement (par exemple dans l’attente de tests de régression sur vos modules), vous pouvez bloquer les attaques automatisées en limitant la profondeur et la taille des flux multipart au niveau de votre serveur web frontal.
Dans la configuration de votre vhost Nginx :
# Réduire la taille maximale autorisée pour les requêtes POST vers les endpoints non-upload
client_max_body_size 8M;
# Bloquer les requêtes multipart avec des payloads anormaux
if ($content_type ~* "multipart/form-data.*boundary=.*boundary=") {
return 403;
}Sous Apache, si vous utilisez mod_security avec l’OWASP Core Rule Set (CRS), assurez-vous que la règle d’inspection des frontières multipart (Rule 920000+) est bien activée en mode bloquant.
Pour vérifier la disponibilité et la réactivité de votre infrastructure après ces modifications, notre Vérificateur d’état de serveur vous permet de confirmer que vos services HTTP et HTTPS répondent sans aucune erreur 502 ou 504. Vous pouvez également analyser la connectivité réseau avec le Vérificateur d’hébergement.
5. Auditer l’intégrité applicative de votre boutique ou site web
Une fois le moteur PHP patché et les processus FPM redémarrés, l’étape suivante consiste à vérifier si des attaquants n’ont pas profité de la fenêtre de vulnérabilité pour déposer une porte dérobée (webshell) persistante sur votre système de fichiers ou injecter des comptes administrateurs cachés dans votre base de données :
- Sur PrestaShop : Vous pouvez inspecter l’ensemble de votre boutique avec le module officiel certifié Genisoft Security Scanner sur PrestaShop Addons (ou explorer sa documentation complète). Ce scanner inspecte en lecture seule le système de fichiers et la base de données pour détecter les obfuscations (
eval,base64_decode), les webshells résiduels et les injections de skimmers dans les templates de commande. - Sur WordPress : Pour surveiller et auditer vos fichiers cœur ainsi que vos extensions contre toute altération furtive, vous pouvez installer l’extension officielle Genisoft Security Connector sur WordPress.org.
Foire aux questions
Est-ce qu’un WAF Cloudflare protège contre php2shell ?
Un pare-feu WAF en périphérie de réseau comme Cloudflare apporte une couche de filtrage utile en bloquant les signatures d’attaque connues et les requêtes multipart anormalement profondes. Cependant, cela ne constitue pas une protection infaillible : des techniques de fragmentation HTTP et d’encodage permettent parfois de contourner les règles WAF. La seule garantie absolue réside dans l’application du correctif sur le moteur PHP lui-même.
Mon site est sur un hébergement mutualisé, suis-je en danger ?
Sur un hébergement mutualisé, vous n’avez pas la main sur le binaire PHP du serveur. Vous dépendez entièrement de la rapidité de votre hébergeur web pour compiler et déployer la mise à jour sur son infrastructure. La quasi-totalité des hébergeurs sérieux déploient ces correctifs critiques sous 24 heures. Vous pouvez vérifier la version active sur votre compte depuis votre panneau de contrôle (cPanel, hPanel, Plesk) ou en créant temporairement un fichier de diagnostic affichant phpinfo().
Comment savoir si mon serveur a déjà été attaqué ?
Dans la mesure où l’exploitation se déroule en mémoire vive dans le processus C, les fichiers journaux applicatifs standards (access.log ou logs d’erreurs PHP) ne contiennent généralement pas de trace directe du code exécuté. En revanche, les tentatives ratées d’exploitation provoquent presque systématiquement des erreurs de type SIGSEGV (Segmentation fault) ou des redémarrages inattendus des workers FPM. Consultez vos logs système via dmesg | grep php-fpm ou /var/log/syslog pour détecter d’éventuels plantages anormaux de processus PHP.
Pourquoi le redémarrage de PHP-FPM est-il indispensable après la mise à jour ?
Sous Linux, remplacer un fichier binaire ou une bibliothèque dynamique sur le disque dur ne modifie pas les processus en cours d’exécution. Les workers PHP-FPM déjà lancés conservent l’ancienne version vulnérable en mémoire vive jusqu’à leur extinction. Sans un redémarrage explicite du service via systemctl restart, votre serveur reste exploitable même si vos gestionnaires de paquets affichent la version corrigée.
