L'essentiel en 30 secondes
- Logiciel
- PHP, le langage qui fait tourner WordPress, sur tous les serveurs qui servent des pages en PHP
- Failles
- CVE-2026-109618 et CVE-2026-109619, note CVSS v4 de 9,2 sur 10 chacune (critique)
- Effet
- Exécution de code sur le serveur, sans mot de passe, avec une seule requête
- Versions corrigées
- PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026
- Sans correctif officiel
- PHP 8.1, 8.0, 7.4 et plus anciennes : seuls l'hébergeur ou la distribution peuvent corriger
- Exploitation
- Tentatives d'attaque signalées dès le 21 octobre ; aucune compromission confirmée publiquement à cette date
Ce que sont les failles PHP2Shell
Chaque page d'un site WordPress est fabriquée par PHP sur le serveur. Les deux failles, surnommées PHP2Shell, se trouvent dans la façon dont PHP gère la mémoire pendant le traitement d'une requête :
- CVE-2026-109618 : quand la mémoire vient à manquer, PHP peut s'interrompre au milieu de la préparation d'une requête, puis traiter ces données inachevées comme si elles étaient valides ;
- CVE-2026-109619 : des données internes d'une requête peuvent survivre à la libération de leur mémoire, et une requête suivante traitée par le même processus peut les réutiliser.
Dans les deux cas, un attaquant peut faire exécuter son propre code par le serveur, sans compte ni mot de passe. Le projet PHP indique que toutes les installations qui servent des pages web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php, où l'attaque peut aboutir avant même que le code du site ne s'exécute.
Ce que l'on sait de l'exploitation
Les détails ont fuité la veille de la publication. Le 21 octobre, Patchstack a reçu des signalements d'hébergeurs, Cloudflare a vu les premières attaques et watchTowr en a observé sur ses leurres. En fin de journée, Patchstack ne constatait encore que des tentatives, sans preuve de compromission. Les deux failles ne figuraient pas encore dans le catalogue des failles exploitées de l'agence américaine CISA.
Votre site est-il concerné ? Trois situations
Demandez la confirmation aujourd'hui
Votre site est en hébergement mutualisé ou infogéré
C'est l'hébergeur qui installe PHP, pas vous. Demandez-lui par écrit si ses serveurs sont passés à une version corrigée, ou ont reçu le correctif de leur distribution. Le modèle d'email plus bas est prêt à envoyer.
Mettre à jour et redémarrer
Vous administrez vous-même le serveur (VPS, dédié, conteneur)
Installez le paquet corrigé de votre distribution ou la version officielle de votre branche, puis redémarrez tous les processus PHP (PHP-FPM, Apache, LiteSpeed). Sans redémarrage, l'ancienne version continue de répondre.
Branche sans correctif officiel
Votre site tourne encore en PHP 8.1 ou plus ancien
Le projet PHP ne publie plus de version pour ces branches. Demandez à votre hébergeur s'il applique un correctif, sinon passez en PHP 8.2 ou plus après avoir vérifié que vos extensions le supportent.
Vous gérez plusieurs sites
Dressez la liste des versions de PHP de chaque site et de chaque hébergeur, sans oublier les copies de préproduction et les conteneurs. Avec WP-CLI, la commande suivante donne la version utilisée par chaque site :
wp eval 'echo PHP_VERSION . PHP_EOL;'Que faire maintenant
Relever la version de PHP du site
Dans l'administration WordPress : Outils, puis Santé du site, onglet Infos, rubrique Serveur. Comparez-la aux versions corrigées. Attention : un paquet de distribution Linux peut être corrigé sans changer de numéro de version, d'où l'intérêt de demander confirmation à l'hébergeur.
wp eval 'echo PHP_VERSION;'Faire mettre PHP à jour
Branche 8.5 : 8.5.12 ou plus. Branche 8.4 : 8.4.27 ou plus. Branche 8.3 : 8.3.36 ou plus. Branche 8.2 : 8.2.35 ou plus ; cette branche n'est plus maintenue après le 31 décembre 2026. Mettre à jour WordPress ou ses extensions ne corrige rien : la faille est dans PHP lui-même.
Si la mise à jour doit attendre : réduire l'exposition
Le projet PHP propose des réglages qui réduisent le risque sans le supprimer. Ils se posent dans la configuration du serveur (php.ini, pool PHP-FPM ou Apache), jamais par ini_set() ou .user.ini, puis tous les processus PHP doivent être redémarrés. Un pare-feu applicatif placé devant le site, comme les règles publiées par Cloudflare, aide aussi, à condition que tout le trafic passe par lui.
memory_limit = -1 ; via php_admin_value si possible
post_max_size = 8M ; 32M si le site reçoit des fichiers
upload_max_filesize = 4M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5 seulementSurveiller les signes d'attaque
Patchstack cite des requêtes d'envoi de fichiers inhabituelles suivies d'erreurs de mémoire ou d'erreurs 500 répétées, des cookies de session PHPSESSID anormalement longs, et des redémarrages de processus PHP inexpliqués. Ces signes ne prouvent rien seuls, mais un serveur qui les montre doit être traité comme potentiellement compromis.
Les réglages d'atténuation viennent de l'avis du projet PHP, qui précise qu'il n'existe aucune mesure complète : seule la mise à jour rend le serveur sûr. Méfiez-vous des extensions ou des extraits de code présentés comme des « correctifs » pour WordPress.
En hébergement mutualisé : demandez la confirmation
Ce message demande à votre hébergeur l'état exact de son serveur. Gardez sa réponse : elle documente ce qui a été fait.
Objet : PHP2Shell (CVE-2026-109618 et CVE-2026-109619) — état de mon hébergement Bonjour, Mon site [adresse du site] est hébergé chez vous (identifiant client : [à compléter]). Le projet PHP a publié le 21/10/2026 des correctifs pour deux failles critiques, CVE-2026-109618 et CVE-2026-109619, qui permettent d'exécuter du code sur le serveur sans authentification. Pourriez-vous me confirmer par écrit : 1. la version de PHP qui sert mon site, et si elle inclut ces correctifs (PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou un paquet corrigé de votre distribution) ; 2. la date à laquelle les correctifs ont été appliqués et les processus PHP redémarrés ; 3. si ma version est la 8.1 ou plus ancienne, la solution que vous proposez ; 4. si vous avez observé des tentatives d'exploitation sur le serveur qui héberge mon site. Merci d'avance pour votre réponse. Cordialement, [Votre nom]
Les indices à vérifier, et ce que notre scan en voit
La faille est dans le serveur, pas dans le site : l'essentiel se vérifie chez l'hébergeur. Le scan sert à chercher ce qu'une attaque réussie aurait laissé dans le site. Nous indiquons pour chaque indice ce que Genisoft Security voit réellement, sans arrondir.
| Indice | Où chercher | Notre scan |
|---|---|---|
| Version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 | Serveur (Outils, Santé du site, Infos) | Non. Notre extension relève la version de PHP, mais le scan ne la compare pas aux correctifs : un paquet de distribution peut être corrigé sous un ancien numéro, et un avis faux serait pire que rien. Seul l'hébergeur peut confirmer. |
| Requêtes d'attaque, erreurs de mémoire, redémarrages de PHP | Journaux du serveur web et de PHP | Non. Le scan lit les fichiers et la base du site, pas les journaux du serveur. Demandez-les à l'hébergeur. |
| Webshell ou porte dérobée déposés après une attaque réussie | Fichiers du site, en particulier wp-content/uploads | En partie. Les webshells connus sont reconnus par nos règles (95,8 % de rappel sur notre corpus de test). Une variante chiffrée peut passer, et un attaquant peut agir hors du dossier du site. |
| Fichier du cœur de WordPress modifié ou ajouté | Dossiers wp-admin et wp-includes | Oui. Chaque fichier du cœur est comparé à son empreinte officielle publiée par WordPress.org. |
| Administrateur créé récemment | Utilisateurs WordPress | En partie. Le scan signale les administrateurs créés depuis moins de 30 jours. À vous de dire s'ils sont légitimes. |
Un serveur exposé à une faille de ce type a pu laisser lire sa mémoire : si une attaque est soupçonnée, renouvelez aussi les mots de passe et les clés que le site utilise (base de données, clés de WordPress, services de paiement et d'emailing).
Votre serveur a été exposé ? Vérifiez ce qu'il reste dans le site
Le scan unique analyse les fichiers et une partie de la base de votre WordPress, et classe chaque élément en menace confirmée, à vérifier ou informatif. Si une menace est confirmée, le Nettoyage accompagné (249 €) remet le site en état pour vous : sauvegarde vérifiée, quarantaine réversible et remplacement par les versions officielles.
Paiement unique, sans abonnement. Il faut créer un compte et installer sur le site notre extension de connexion, qui fonctionne en lecture seule. Le scan ne vérifie ni le serveur ni les secrets : ces étapes restent à faire.
Ce que PHP2Shell rappelle sur l'hébergement
WordPress repose sur PHP, et PHP sur l'hébergeur
Un site à jour de ses extensions peut rester vulnérable si la couche du dessous ne l'est pas. Savoir qui met PHP à jour, et sous quel délai, fait partie du choix d'un hébergeur.
Une version de PHP non maintenue est une dette
PHP 8.1 et les versions plus anciennes ne reçoivent plus de correctifs du projet. Une faille comme celle-ci ne s'y corrige qu'au bon vouloir de l'hébergeur. Prévoyez la montée de version avant la fin de vie, pas après.
Une extension de sécurité ne voit pas tout
L'attaque peut aboutir avant même que WordPress ne démarre, donc avant toute extension. Les protections utiles sont en amont : mise à jour du serveur, pare-feu placé devant le site.
Après une faille du serveur, vérifiez le site
Si le serveur a été exposé, un scan du site cherche ce qu'un attaquant aurait pu y laisser : fichiers ajoutés, cœur modifié, comptes créés.
Pour aller plus loin, notre checklist pour sécuriser WordPress reprend les gestes qui réduisent vraiment le risque, et notre méthodologie détaille ce que le scan analyse et ce qu'il ne voit pas.
Questions fréquentes
J'ai mis à jour WordPress et toutes mes extensions : suis-je protégé ?
Non. La faille est dans PHP, le programme qui exécute WordPress sur le serveur. Seule une mise à jour de PHP, faite par votre hébergeur ou par vous si vous gérez le serveur, la corrige.
Mon extension de sécurité me protège-t-elle ?
Pas contre cette faille. Le projet PHP indique qu'avec Apache et mod_php, une requête peut déclencher l'attaque avant que le code de l'application ne s'exécute, donc avant WordPress et ses extensions. Un pare-feu placé devant le serveur, comme celui de Cloudflare, réduit le risque si tout le trafic passe par lui.
Comment savoir si mon hébergeur a corrigé ?
Relevez la version de PHP dans Outils, puis Santé du site, et comparez-la aux versions corrigées. Si elle est plus ancienne, cela ne prouve pas que le serveur est vulnérable : certaines distributions Linux corrigent sans changer de numéro. Demandez une confirmation écrite à l'hébergeur avec le modèle ci-dessus.
Mon site est en PHP 7.4 : que faire ?
Le projet PHP ne publie pas de nouvelle version pour la 7.4, seulement un correctif à recompiler, destiné aux distributions et aux personnes qui compilent PHP elles-mêmes. Demandez à votre hébergeur s'il l'applique, et planifiez le passage à PHP 8.2 ou plus : vérifiez d'abord sur une copie du site que vos extensions et votre thème le supportent.
Faut-il mettre le site hors ligne ?
Le centre national de cybersécurité britannique (NCSC) conseille de déconnecter les systèmes qui ne peuvent pas être corrigés rapidement. Pour un site qui traite des paiements ou des données de clients, le mode maintenance en attendant la confirmation de l'hébergeur est une précaution raisonnable.
Chronologie et sources
| Date | Événement |
|---|---|
| Le projet PHP annonce une mise à jour de sécurité critique pour le lendemain. Des détails fuitent avant la publication coordonnée. | |
| Le matin, Patchstack et Cloudflare signalent les premières tentatives d'attaque ; watchTowr en observe sur ses leurres. PHP publie comme prévu les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. | |
| Prévu : fin de maintenance de la branche PHP 8.2. |
- Projet PHP, avis de sécurité du 21 octobre 2026 et fiches CVE-2026-109618 et CVE-2026-109619 (en anglais). Source de référence pour les versions et les mesures.
- Patchstack, alerte suivie en direct, 21 octobre 2026 (en anglais) : signalements d'hébergeurs et signes d'attaque.
- watchTowr, questions-réponses, 21 octobre 2026 (en anglais) : exploitation observée sur leurres.
- Help Net Security, article sur les correctifs, 21 octobre 2026 (en anglais) : environnements touchés, règles Cloudflare et conseil du NCSC.
La situation évolue d'heure en heure : l'avis du projet PHP reste la référence en cas d'écart avec cette page, dont la date de mise à jour figure en tête d'article.
Voir à quoi ressemble un vrai rapport
Nous publions un rapport de scan réel, consultable sans créer de compte. Vous y verrez comment chaque élément est classé, et pourquoi un fichier signalé n'est pas forcément une infection.
