État vérifié le 22 octobre 2026 : hébergeurs à 13 h 45, failles WordPress à 16 h 50, heure de Paris.
Que faire aujourd'hui si votre site tourne sous PHP ?
Si votre site tourne sous PHP, lisez ce que votre hébergeur annonce sur le correctif du 21 octobre 2026, vérifiez la version servie quand son numéro change, et demandez une réponse écrite en cas de doute. L'équipe PHP est nette : aucun contournement n'est complet, seule la mise à jour est sûre.
- Testez votre site avec le vérificateur ci dessous, ou lisez votre version de PHP.
- Comparez cette version au tableau des versions corrigées.
- Lisez l'annonce de votre hébergeur, puis, en cas de doute, demandez une réponse écrite.
- En PHP 8.1 ou avant, voyez les trois voies.
- Après la correction, testez formulaire et Search Console.
Vérificateur gratuit
Ce que votre site affiche de sa version de PHP
Le test lit ce que votre site affiche publiquement, comme un navigateur. Il ne teste pas la faille et rien n'est enregistré.
La faille PHP2Shell, c'est quoi ?
PHP2Shell désigne deux failles du moteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 par l'équipe PHP. Une requête fabriquée peut faire exécuter du code sur le serveur sans mot de passe, et sur Apache avec mod_php avant même que WordPress ne démarre (php.net, 21/10/2026).
L'attaquant agit alors avec les droits du serveur web et peut lire la mémoire de PHP, où passent mots de passe et clés API (php2shell.com, site des chercheurs de Wiz, OpenAI et Calif, qui l'ont baptisée). PHP sert 69,3 % des sites dont le langage serveur est connu (W3Techs, 22/10/2026), et un WordPress à jour reste exposé. Le risque est maximal avec mod_php ; avec PHP-FPM, l'autre configuration courante (OVHcloud), l'exécution de code est aussi confirmée, par des chemins qui passent par le code de l'application (PHP Foundation).
Quel est le danger réel de cette faille pour votre entreprise ?
Le danger est qu'un inconnu agisse sur votre serveur avec les mêmes droits que votre site : lire vos fichiers et votre base de données, récupérer les mots de passe et clés que PHP garde en mémoire, puis modifier vos pages.
| Ce qu'un attaquant peut faire | Ce que cela vous coûte | Source |
|---|---|---|
| faire exécuter son code avec les droits du serveur web | vos fichiers et votre base de données : comptes clients, demandes de devis, commandes | PHP Foundation et php2shell.com |
| lire la mémoire de PHP, sans même exécuter de code | mots de passe, jetons de connexion, clés d'API et certificats | php2shell.com |
| modifier votre site : pages de spam, redirections, logiciel malveillant | un avertissement de Google dans le rapport « Problèmes de sécurité », puis des visites et des demandes perdues | |
| se servir de votre site pour piéger d'autres personnes | une suspension par l'hébergeur et une image abîmée auprès de vos clients | Google, WordPress.org |
| emporter des données personnelles | une notification à la CNIL dans les meilleurs délais, si possible sous 72 heures après la découverte, sauf absence de risque pour les personnes | RGPD, article 33 |
Mettre PHP à jour, puis le redémarrer, ferme la porte, mais ne chasse pas un intrus déjà entré et ne rend pas secrets des mots de passe déjà lus. Tout site PHP a tourné sans correctif au moins du 17 octobre 2026, date de la première tentative repérée par Amazon, jusqu'à sa mise à jour : cherchez les signes d'une attaque et faites changer les mots de passe et les clés d'API.
Comment savoir si votre site est concerné ?
Tout site dont les pages sont produites par PHP est concerné tant que son serveur n'a pas reçu le correctif, qu'il tourne sous WordPress, PrestaShop, Drupal, Joomla, Magento ou un code sur mesure. L'avis de php.net du 21 octobre 2026 vise toutes les installations qui servent des pages web.
| Où lire la version de PHP | À savoir |
|---|---|
| WordPress : Outils, Santé du site, onglet Informations, section Serveur | la version qui sert le site |
| PrestaShop : Paramètres avancés, Informations | la version qui sert la boutique |
| Espace client de l'hébergeur (cPanel, Plesk, Manager) | la version choisie pour le site |
En tête X-Powered-By des réponses du site |
affiché seulement si la directive expose_php est active ; visible aussi par un attaquant : faites couper cet affichage |
php -v, en SSH |
la version de la ligne de commande, qui peut différer de celle du site (OVHcloud) |
Page phpinfo() |
version et date de compilation, mais aussi toute la configuration (php.net) : à créer puis supprimer par votre prestataire |
Quelles versions de PHP corrigent la faille ?
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026 par l'équipe PHP. PHP 8.1 et avant n'ont plus de version officielle : l'équipe PHP a seulement publié des correctifs de sources pour 7.4, 8.0 et 8.1.
| Branche | Version corrigée | Correctifs de sécurité jusqu'au | Ce que vous faites |
|---|---|---|---|
| 8.5 | 8.5.12 | 31/12/2029 | mettre à jour |
| 8.4 | 8.4.27 | 31/12/2028 | mettre à jour |
| 8.3 | 8.3.36 | 31/12/2027 | mettre à jour |
| 8.2 | 8.2.35 | 31/12/2026 | mettre à jour, puis passer en 8.3 ou plus avant le 31/12/2026 |
| 8.1, 8.0, 7.4 | aucune version officielle, correctifs de sources seulement | fin de vie (8.1 depuis le 31/12/2025) | paquet corrigé de l'hébergeur ou de la distribution, ou migration |
| 7.3 et avant | aucun correctif du projet PHP ; affectées selon le CERT FR | fin de vie | migration ou mise hors ligne |
Pourquoi le numéro de version ne prouve pas que votre site est corrigé ?
Le numéro de version ne prouve pas le correctif, parce qu'Ubuntu, Infomaniak, Hostinger et o2switch corrigent PHP sans toujours changer le numéro affiché : le PHP corrigé d'Ubuntu 24.04 affiche toujours 8.3.6 (Ubuntu, 21 octobre 2026). Le numéro ne tranche que lorsqu'il change, comme chez Debian, qui publie 8.2.35 et 8.4.27.
Le numéro lu sur le site (Santé du site, X-Powered-By, phpinfo()) vient du processus PHP qui répond : corrigé, il prouve que ce processus tourne sur la version corrigée, sauf si plusieurs serveurs se partagent le site. Le numéro de php -v ou du paquet ne le prouve pas : sans redémarrage, l'ancienne version reste en mémoire (OVHcloud).
| Où | Version affichée | Ce qui prouve le correctif | Source |
|---|---|---|---|
| Ubuntu 24.04 | 8.3.6 | paquet 8.3.6-0ubuntu0.24.04.13 |
USN-8948-1, 21/10/2026 |
| Ubuntu 22.04 | 8.1.2, branche 8.1 corrigée par Ubuntu | paquet 8.1.2-1ubuntu2.28 |
USN-8948-1, 21/10/2026 |
| Debian 13 et Debian 12 | 8.4.27 et 8.2.35 : le numéro change | le numéro, paquets 8.4.27-1~deb13u1 et 8.2.35-1~deb12u1 |
DSA-6574-1, DLA-4848-1 |
| o2switch | numéro parfois inchangé : 8.3.35 pour PHP 8.3 | date de compilation au 21/10/2026 (paquet 8.3.35-6) |
o2switch, 22/10/2026 |
| Hostinger | numéro parfois inchangé | date de compilation au 21/10/2026 ou après, dans PHP Info | Hostinger, 22/10/2026 |
| Infomaniak | numéros inchangés, de 7.4 à 8.5 | l'annonce de l'hébergeur | Infomaniak, 22/10/2026 |
Notre relevé du 22 octobre 2026 sur 58 sites de nos clients, par l'en tête HTTP X-Powered-By, le confirme : 45 sites sur 58 (78 %) n'affichent aucune version, et 13 l'affichent.
| Ce qu'affichent les 13 sites | Sites | Ce qu'on peut en conclure |
|---|---|---|
| un numéro corrigé : 8.2.35, 8.3.36, 8.4.27 | 3 | le processus qui répond tourne sur une version corrigée |
| un numéro antérieur au correctif : 8.2.34 trois fois, 8.3.35 une fois | 4 | rien : le numéro peut rester inchangé après correction |
| une branche en fin de vie : 7.4, 8.0, 8.1 | 3 | rien sur le correctif ; une migration à prévoir |
| la branche seule : 8.2, 8.2, 8.4 | 3 | rien : le niveau de correctif ne s'y lit pas |
Pour 9 des 10 sites qui n'affichent pas un numéro corrigé, l'hébergeur mutualisé annonce avoir appliqué le correctif : OVHcloud, de 7.4 à 8.5 sur tous ses clusters, et Hostinger, de 5.2 à 8.5 avec un numéro parfois inchangé. Le dixième est chez un hébergeur qui annonce un déploiement encore en cours le 22 octobre 2026. Pour ces dix sites, le numéro affiché ne prouve donc ni la faille ni le correctif : il faut la réponse de l'hébergeur.
Qui doit corriger votre site, vous ou votre hébergeur ?
Sur un hébergement mutualisé ou infogéré, l'hébergeur installe le correctif de PHP ; sur un VPS, un serveur dédié ou une image Docker, c'est vous ou votre prestataire. OVHcloud, IONOS et Hostinger l'écrivent les 21 et 22 octobre 2026 : ils corrigent le mutualisé, le VPS reste à la charge du client.
| Votre hébergement | Qui installe le correctif | Ce que vous faites | Comment vérifier |
|---|---|---|---|
| Mutualisé (OVHcloud, o2switch, Infomaniak, IONOS, Hostinger, LWS, Scaleway) | l'hébergeur, pour les versions qu'il maintient | passer en 8.3 ou 8.4 si le site est en 8.1 ou avant | son annonce, puis la version servie si le numéro change, puis une réponse écrite en cas de doute |
| Infogéré ou WordPress managé | le prestataire ou l'hébergeur infogérant | lire son annonce ; en cas de doute, demander une réponse écrite | une annonce ou une réponse qui cite les deux CVE |
| VPS ou dédié sous Debian ou Ubuntu | vous ou votre prestataire | mise à jour des paquets PHP, puis redémarrage de PHP | paquet comparé à l'avis : Debian 13 8.4.27-1~deb13u1 (DSA-6574-1), Debian 12 8.2.35-1~deb12u1 (DLA-4848-1), Ubuntu (USN-8948-1) |
| VPS ou dédié sous RHEL, AlmaLinux ou Rocky Linux | vous ou votre prestataire | mise à jour des paquets PHP, puis redémarrage | l'avis de l'éditeur de la distribution |
| Docker | vous ou votre prestataire | reconstruire l'image sur une image PHP corrigée, puis redéployer : mettre à jour l'hôte ne change rien au conteneur (Microsoft) | la version lue dans le conteneur |
| PHP 8.1 ou plus ancien, partout | personne par défaut | voir plus bas | voir plus bas |
Commandes pour un VPS ou un dédié qui utilise le PHP de sa distribution, à laisser à votre prestataire technique après une sauvegarde :
| Étape | Debian | Ubuntu | AlmaLinux ou Rocky Linux |
|---|---|---|---|
| Mettre à jour PHP seulement | sudo apt-get update, puis sudo apt-get install --only-upgrade suivi de tous les paquets PHP installés issus de php8.4 sur Debian 13 ou de php8.2 sur Debian 12 (FAQ de sécurité de Debian) |
déconseillé par Ubuntu, qui recommande la mise à jour complète | sudo dnf upgrade 'php*' (Red Hat, documentation de dnf) |
| Tout mettre à jour : tous les paquets du système, pas seulement PHP | sudo apt update && sudo apt upgrade (OVHcloud) |
sudo apt update && sudo apt upgrade (Ubuntu, OVHcloud) ; en 20.04, le paquet 7.4 corrigé n'arrive qu'avec Ubuntu Pro activé |
sudo dnf upgrade (OVHcloud) |
Redémarrer PHP-FPM |
sudo systemctl restart php8.4-fpm (Debian 13) ou php8.2-fpm (Debian 12) |
sudo systemctl restart php8.3-fpm (24.04), php8.1-fpm (22.04) ou php7.4-fpm (20.04) |
sudo systemctl restart php-fpm |
| Redémarrer Apache | sudo systemctl restart apache2 |
sudo systemctl restart apache2 |
sudo systemctl restart httpd |
Si un prestataire gère votre site, la mise à jour de PHP relève de son contrat, et vos accès doivent être à votre nom : voyez ce que doit couvrir un contrat de maintenance.
Où en sont les hébergeurs ?
Relevé du 22 octobre 2026 à 13 h 45, heure de Paris, sur la page de chaque hébergeur.
| Hébergeur | État annoncé | Annonce | Ce qui reste à faire chez vous |
|---|---|---|---|
| OVHcloud, hébergement web | toutes les versions de 7.4 à 8.5 corrigées sur tous les clusters ; versions antérieures en cours ; règles de pare feu posées | 21/10/2026, 17 h 53 UTC | migrer si moins de 7.4 ; VPS et Bare Metal à votre charge |
| o2switch | version native de tous les serveurs mise à jour le 21/10, correctifs actifs ; versions 5.2 à 8.5 du sélecteur cPanel corrigées avec les correctifs disponibles à ce jour ; numéro parfois inchangé | 22/10/2026, 8 h 33 UTC | vérifier la date de compilation ; tester vos formulaires avec pièce jointe : envois de fichiers filtrés plus strictement et barre de progression coupée jusqu'à confirmation des correctifs ; migrer si moins de 5.2 |
| Infomaniak | correctifs déployés sur l'hébergement web mutualisé et les Serveurs Cloud, de 7.4 à 8.5 ; numéros inchangés | 22/10/2026, 7 h 42 (fuseau non précisé) | migrer si moins de 7.4 |
| Hostinger | correctif installé sur tous les serveurs sauf VPS, déploiement terminé le 22/10 à 6 h 44 UTC ; versions 5.2 à 8.5 corrigées sur l'hébergement Web, Cloud et cPanel ; numéro parfois inchangé | 22/10/2026, 7 h 20 UTC | lire la date de compilation dans PHP Info ; VPS : mise à jour et redémarrage par vous |
| LWS | correctif installé sur tous les mutualisés, anciennes versions comprises ; blocage temporaire des envois de fichiers levé | 22/10/2026, 8 h (fuseau non précisé) | tester vos formulaires ; VPS non infogérés : suivre l'email reçu |
| IONOS | mises à jour officielles déployées sur toutes les plateformes exploitées par IONOS ; incident clos | 22/10/2026, 13 h 07, heure de Paris (page d'état) | VPS et serveurs dédiés : mise à jour par vous |
| Scaleway | cPanel et Plesk corrigés ; hébergement mutualisé classique encore en maintenance ; sites mis hors ligne par précaution le 21/10 | 22/10/2026, 8 h 20, heure de Paris | attendre la réouverture, puis vérifier |
| PlanetHoster | aucune communication publique trouvée le 22/10/2026, ni sur sa page d'état, ni sur son blog, ni par recherche web | aucune | demander l'état du correctif à son support |
Pour votre site, la preuve du correctif se lit dans cet ordre : l'annonce de l'hébergeur, puis la version servie quand le numéro change, puis une réponse écrite en cas de doute.
Que demander par écrit à votre hébergeur ou à votre prestataire ?
En cas de doute sur le correctif, demandez à votre hébergeur ou à votre prestataire une réponse écrite à trois questions : le correctif des failles CVE-2026-109618 et CVE-2026-109619 est installé sur le serveur de votre site, à quelle date les processus PHP ont redémarré, et quelle version sert réellement votre site.
Bonjour, notre site internet tourne sous PHP. Merci de nous confirmer par écrit trois points : le correctif des failles
CVE-2026-109618etCVE-2026-109619, publié par PHP le 21 octobre 2026, est installé sur le serveur qui sert notre site ; la version et le paquet PHP réellement utilisés par notre site ; la date à laquelle les processus PHP ont été redémarrés. Si notre version de PHP n'est plus maintenue, dites nous quelles options vous proposez et dans quel délai. Merci.
Écrivez depuis votre espace client : IONOS signale de faux emails sur la faille, faits pour voler des identifiants. Sans les deux CVE ni la date du redémarrage, relancez.
Envoyez nous l'adresse de votre site : sous 24 h, nous vous disons ce qu'il affiche de sa version de PHP et quoi demander à votre hébergeur, y compris quand le site n'affiche rien, le cas de 45 de nos 58 sites clients. C'est gratuit.
Votre site tourne en PHP 8.1 ou plus ancien : que faire ?
Aucune version officielle ne corrige PHP 8.1, 8.0 ou 7.4 : il faut un paquet corrigé par votre distribution ou votre hébergeur, ou passer en PHP 8.3 ou 8.4. Le CERT FR recommande d'isoler les serveurs aux versions non maintenues, puis de migrer (alerte CERTFR-2026-ALE-014, 21 octobre 2026).
| Voie, dans cet ordre | Quand | Exemples et limites |
|---|---|---|
| 1. Un paquet corrigé de votre version | votre hébergeur ou votre distribution le fournit | Ubuntu 22.04 en 8.1 ; Ubuntu Pro pour 7.4 sur Ubuntu 20.04 (7.4.3-4ubuntu2.29+esm5) ; OVHcloud, o2switch, Hostinger, Infomaniak et LWS annoncent couvrir leurs anciennes versions |
| 2. Une migration vers PHP 8.3 ou 8.4 | le thème, les extensions ou les modules le supportent | sauvegarde et copie de test d'abord ; WordPress recommande 8.3 ou plus ; PrestaShop 9 accepte 8.1 à 8.5, les boutiques 1.7 et 8 tournent souvent en PHP 7 ou 8.1 |
| 3. La mise hors ligne | aucune des deux voies n'est possible tout de suite | ce que demande la CISA le 21/10/2026 ; voir comment garder Google |
L'image Docker officielle php:8.1 n'a plus été reconstruite depuis le 2 janvier 2026 (Docker Hub) : elle n'a pas le correctif. Pour votre boutique PrestaShop, l'éditeur déconseille de précipiter une mise à niveau majeure : la priorité est un PHP corrigé. Si le thème ou les extensions ne suivent pas la migration, il peut falloir refaire le site sur une version de PHP maintenue, et changer de version sans perdre votre référencement.
Que faire si la mise à jour est impossible tout de suite ?
Si la mise à jour de PHP est impossible tout de suite, réduisez l'exposition : pare feu applicatif, suivi de progression des envois coupé, envois de fichiers bloqués si le site n'en reçoit pas. L'équipe PHP précise le 21 octobre 2026 que ces mesures ne rendent pas l'installation sûre, et le CERT FR ne les a pas qualifiées.
| Mesure | Qui la pose | Ce qu'elle bloque | Ce qu'elle peut casser |
|---|---|---|---|
| Pare feu applicatif de l'hébergeur ou de Cloudflare | l'hébergeur ; Cloudflare l'active par défaut sur tous ses plans, gratuit compris, depuis le 21/10 à 3 h 02 UTC | les attaques connues | rien d'annoncé ; ne protège que le trafic qui passe par Cloudflare |
Désactiver session.upload_progress.enabled |
l'hébergeur ou l'administrateur, dans php.ini ou le pool, jamais par .user.ini ni ini_set(), puis redémarrage |
une seule des deux failles, sur les chemins confirmés | la barre de progression des envois |
Bloquer les requêtes multipart (envois de fichiers) |
l'hébergeur ou l'administrateur, au pare feu applicatif | les déclencheurs connus | les formulaires avec pièce jointe, des imports, certains formulaires envoyés en JavaScript |
memory_limit = -1, cité par l'avis de PHP |
le prestataire technique seulement | une partie de la première faille | une seule requête peut consommer toute la mémoire du serveur (OVHcloud) |
| Mettre le site hors ligne | l'hébergeur ou l'administrateur | toute attaque pendant la coupure | le référencement si la coupure dépasse deux jours ou si le code n'est pas 503 |
Mettre le site hors ligne sans perdre Google
Servez une page de maintenance en code 503, jamais en 403, 404, 410 ni noindex, en laissant le fichier robots.txt hors de ce 503, et rouvrez sous deux jours : au delà, Google retire ces adresses de son index (Google Search Central). Servez cette page sans PHP : l'attaque peut partir avant le code du site, et aucune mesure prise dans l'application ne la bloque (PrestaShop). Nous en déduisons que le mode maintenance de WordPress ou de PrestaShop, servi par PHP, ne protège pas.
Comment savoir si votre site a déjà été attaqué ?
Pour savoir si votre site a déjà été attaqué, cherchez les signes publiés par Wiz et la CISA : envois inhabituels suivis d'erreurs de mémoire ou d'erreurs 500 répétées, cookies PHPSESSID anormaux, processus PHP qui redémarrent ou lancent des commandes. L'avis de PHP du 21 octobre 2026 prévient qu'un journal sans erreur ne prouve pas que le site est sain.
Surveillez depuis le 17 octobre 2026, date de la première tentative repérée par Amazon sur ses leurres.
| Ce qui est dit sur les attaques | Qui le dit | Statut au 22/10/2026 |
|---|---|---|
| aucune exploitation observée à la publication de son alerte, le 21/10 | CISA | établi |
| les deux failles absentes du catalogue des failles exploitées, version du 21/10 | CISA, catalogue lu le 22/10 | établi |
| une tentative le 17/10, puis une exploitation « large », sans savoir si les tentatives réussissent | Amazon | déclaration, non vérifiable |
| du trafic d'attaque vers ses clients | Cloudflare | déclaration, non vérifiable |
Les signes visibles sans compétence technique (WordPress.org, aide Search Console) :
| Signe | Où le voir |
|---|---|
| un utilisateur ou un administrateur que personne n'a créé | la liste des utilisateurs du site |
| une alerte de sécurité | le rapport « Problèmes de sécurité » de la Search Console |
| un site suspendu par l'hébergeur | les emails et l'espace client de l'hébergeur |
| un site signalé pour logiciel malveillant | les avertissements de Google et des navigateurs |
| un antivirus qui bloque votre site | les retours de vos visiteurs |
La lecture de la mémoire, possible sans exécuter de code, se détecte mal (php2shell.com) : faites changer par votre prestataire les mots de passe et les clés d'API que le site utilise. Amazon lui fournit six adresses IP à investiguer plutôt qu'à bloquer (blog sécurité AWS).
Que faire si votre site a été piraté ?
Si votre site a été piraté, coupez son accès, conservez les journaux, déposez plainte avant toute réinstallation, puis restaurez une sauvegarde saine et changez tous les mots de passe. Si des données personnelles ont pu fuiter, l'article 33 du RGPD impose de notifier la CNIL, si possible sous 72 heures, sauf absence de risque pour les personnes.
La fiche réflexe de Cybermalveillance.gouv.fr, résumée :
- Confinez les équipements touchés et coupez leurs accès réseau.
- Cherchez l'origine de l'intrusion et toute activité inhabituelle.
- Récupérez les journaux du serveur et du pare feu, qui servent de preuves.
- Déposez plainte avant de réinstaller.
- Réinstallez depuis une sauvegarde antérieure à l'incident.
- Changez tous les mots de passe et mettez PHP à jour avant la remise en ligne.
Le diagnostic en ligne 17Cyber oriente vers une aide. ForgeOne n'est pas une société de cybersécurité : pour analyser une intrusion, faites appel à un prestataire référencé sur Cybermalveillance.gouv.fr.
Après la correction, que vérifier sur votre site ?
Après la correction de PHP, vérifiez le jour même la version réellement servie, votre formulaire de devis avec une pièce jointe, et la Search Console. Les mesures d'urgence ont bloqué des envois de fichiers chez certains hébergeurs, comme LWS jusqu'au 22 octobre 2026 au matin, et un formulaire muet fait perdre des demandes sans alerte.
Dans nos 262 appels de vente, 17 acheteurs sur 170 perdaient déjà des demandes dans un dispositif cassé, formulaire muet compris. Écrivez dans votre contrat de maintenance qui doit faire ces contrôles après chaque mise à jour de PHP.
| Contrôle | Où | Pourquoi |
|---|---|---|
| Envoyer une demande de devis test avec pièce jointe | votre formulaire, puis la boîte qui reçoit les demandes | seule la réception prouve que l'envoi passe |
| Lire la version servie | Santé du site ou espace client | si le numéro a changé, il confirme le correctif ; sinon, fiez vous à l'annonce ou à la réponse écrite |
| Ouvrir le rapport « Problèmes de sécurité » | Search Console | Google y signale un site piraté |
| Regarder les jours de coupure | Search Console, Paramètres, Statistiques sur l'exploration | des 503 prolongés font sortir des pages de l'index |
| Noter la migration vers 8.3 ou 8.4 avant le 31/12/2026 si le site est en 8.2 | votre agenda | fin des correctifs de 8.2 (php.net) |
Faille WordPress ou faille PHP : que faire si votre site tourne sous WordPress ?
PHP2Shell n'est pas une faille WordPress : la faille est dans PHP, le langage qui fait tourner WordPress, donc une mise à jour de WordPress ne la corrige pas et une extension de sécurité ne la bloque pas. Un site WordPress a besoin de deux correctifs : celui de PHP, posé par l'hébergeur ou le prestataire, et ceux de WordPress.
WordPress.org l'écrit le 21 octobre 2026 : PHP2Shell touche tout serveur qui héberge une application PHP, et aucune mise à jour de WordPress n'est requise ni prévue. PrestaShop précise qu'une mesure prise dans l'application ne peut pas bloquer l'attaque.
| Faille | Où elle se trouve | Qui la corrige | Où le vérifier |
|---|---|---|---|
| PHP2Shell | dans PHP, sous WordPress | l'hébergeur en mutualisé ; vous ou votre prestataire sur un VPS ou un dédié | le vérificateur, puis l'annonce de votre hébergeur |
| une faille du cœur de WordPress | dans les fichiers de WordPress | WordPress.org, par une version de sécurité que la plupart des sites installent automatiquement | Tableau de bord, Mises à jour |
| une faille d'une extension ou d'un thème | dans son code | son éditeur publie le correctif ; la mise à jour reste à faire sur votre site, sauf mise à jour automatique activée | Tableau de bord, Mises à jour, parties Extensions et Thèmes |
Quelles failles WordPress ont été corrigées en 2026 ?
En 2026, WordPress.org a corrigé deux failles critiques du cœur de WordPress, en juillet puis en septembre, et la CISA les a ajoutées à son catalogue des failles exploitées. Les autres versions de sécurité de l'année corrigent des failles notées élevées, ou des lots de failles dont WordPress ne publie pas la gravité.
| Correction | Faille | Gravité selon WordPress | Exploitée selon la CISA |
|---|---|---|---|
| 17 juillet 2026 : 7.0.2, 6.9.5 et 6.8.6 | CVE-2026-63030 (API REST) et CVE-2026-60137 (injection SQL) : ensemble, elles permettent à un visiteur sans compte d'exécuter du code en 6.9 et 7.0 ; la 6.8 n'a que l'injection SQL ; avant 6.8, aucune des deux |
critique pour CVE-2026-63030 ; élevée pour CVE-2026-60137 selon la note de version (moyenne selon l'avis GitHub) ; mise à jour automatique forcée par WordPress.org |
oui, depuis le 21 juillet |
| 22 septembre 2026 : 7.1.2, et chaque branche depuis 4.7 | CVE-2026-87902 : un visiteur sans compte peut faire charger un fichier PHP du serveur, jusqu'à exécuter du code sous deux conditions, détaillées sous le tableau |
critique, 9,2 sur 10 | oui, depuis le 25 septembre |
| 6 août 2026 : 7.0.3, et chaque branche depuis 4.7 | CVE-2026-64638 : un script glissé dans l'écran de connexion, jusqu'à l'exécution de code si la personne visée se laisse attirer sur un site piégé ; 11 autres failles corrigées |
élevée, 8,9 sur 10 | non |
| 12 août 2026 : 7.0.4, et chaque branche depuis 4.7 | CVE-2026-65640 : un compte Auteur ou plus peut exécuter du code par un fichier piégé, si le serveur utilise Imagick et Ghostscript |
élevée, 8,8 sur 10 | non |
| 10 et 11 mars 2026 : 6.9.2, puis 6.9.4 | 10 failles, dont une requête forcée depuis le serveur (SSRF) et des injections de script (XSS) | non publiée | non |
| 17 septembre 2026 : 7.1.1 | 11 failles, dont une injection de script par un visiteur sans compte, si son commentaire est approuvé | non publiée | non |
| 6 octobre 2026 : 7.1.3 | 7 failles, dont une injection SQL dans l'export des contenus | non publiée | non |
« Non » veut dire absente du catalogue de la CISA dans sa version du 21 octobre 2026. Sur les failles de juillet, Cybermalveillance.gouv.fr a lancé une AlerteCyber le 23 juillet 2026.
Pour la faille de septembre, WordPress cite deux conditions : un thème qui contient un dossier dont le nom commence par page-, comme Twenty Twelve, Twenty Fourteen, Neve, Hestia ou Sydney, et un fichier PHP exploitable sur le serveur, comme pearcmd.php quand le réglage register_argc_argv de PHP est actif. C'est le cas de l'image Docker officielle de PHP, et de cPanel par défaut avant PHP 8.5.
WordPress.org ne maintient activement que la dernière version de WordPress : 7.1.3 au 22 octobre 2026.
Les extensions restent la première source de failles : au 22 octobre 2026, la base Patchstack recense 10 364 failles de l'écosystème WordPress pour l'année 2026, dont 9 244 dans des extensions (89 %), 1 084 dans des thèmes et 36 dans le cœur. Par défaut, WordPress ne met pas à jour les extensions automatiquement, sauf cas décidés par son équipe de sécurité pour une faille critique.
Comment savoir où en est votre WordPress ?
Pour savoir où en est votre WordPress, ouvrez trois écrans de l'administration : Tableau de bord, Mises à jour ; Outils, Santé du site ; Extensions, Extensions installées. Les libellés cités sont ceux de l'interface française de WordPress.
| Où cliquer | Ce que vous devez lire | Ce que veut dire l'autre message |
|---|---|---|
| Tableau de bord, Mises à jour | « Vous avez la dernière version de WordPress. » | un bouton qui commence par « Mettre à jour vers la version 7.1.3 » : votre site n'a pas la dernière version |
| le même écran, sous la version | « Ce site est automatiquement mis à jour avec uniquement les versions de maintenance et de sécurité de WordPress. », ou « avec chaque nouvelle version de WordPress. » | « Ce site ne recevra pas de mise à jour automatique pour les nouvelles versions de WordPress. » : demandez à votre prestataire qui installe les versions de sécurité, et sous quel délai |
| le même écran, partie Extensions | « Vos extensions sont toutes à jour. » | la liste des extensions qui attendent leur mise à jour |
| Outils, Santé du site, onglet État | aucun problème critique, ni « Vous avez des extensions en attente de mise à jour », ni « Vous devriez retirer les extensions inactives » | « Vous devriez retirer les extensions inactives » : WordPress les décrit comme des cibles tentantes pour les attaquants, et ce message peut cacher des extensions en attente de mise à jour : ouvrez le pour lire leur nombre |
| Outils, Santé du site, onglet Informations, section Serveur | la version de PHP | à comparer au tableau des versions corrigées, sans oublier que le numéro ne prouve pas tout |
| Extensions, Extensions installées, colonne « Mises à jour automatiques » | « Désactiver les mises à jour auto » : l'extension se met à jour seule | « Activer les mises à jour auto » : l'extension attend une mise à jour manuelle ; sans cette colonne, l'hébergeur ou une extension a sans doute coupé la fonction (WordPress.org) |
Quelle version de PHP choisir pour WordPress ?
PHP 8.3 ou plus, recommandé par WordPress.org ; les dates de fin des correctifs sont dans le tableau des versions.
Envoyez nous l'adresse de votre site : sous 24 h, nous vous disons ce qu'il affiche de sa version de PHP et quoi demander à votre hébergeur, y compris quand le site n'affiche rien, le cas de 45 de nos 58 sites clients. C'est gratuit.
Vérification gratuite
Demandez la vérification de votre site
Sous 24 h, nous vous disons ce que votre site affiche de sa version de PHP et quoi demander à votre hébergeur, y compris quand le site n'affiche rien.
Sources
Pages ouvertes le 22 octobre 2026 entre 12 h 10 et 13 h 45, heure de Paris ; celles sur les failles WordPress, entre 16 h 20 et 16 h 50. Le relevé des 58 sites de nos clients a été fait par ForgeOne le 22 octobre 2026 : la version de PHP vient de l'en tête HTTP X-Powered-By de leurs réponses, l'hébergeur des 10 sites au numéro douteux vient de leur adresse IP et de son réseau. Il est publié sans nommer les clients. Le compte des acheteurs vient de 262 appels enregistrés par ForgeOne avec 170 acheteurs, de décembre 2024 à septembre 2026.
- php.net, annonce de sécurité et versions corrigées, 21 octobre 2026, et archives 2026 (préannonce du 20 octobre, notes de version) ;
- PHP, avis GitHub
GHSA-w8hw-w9fx-j79w(CVE-2026-109618) etGHSA-6wmf-4rv5-p3rp(CVE-2026-109619) ; - php.net, versions maintenues et branches en fin de vie ;
- php.net, manuel : directive expose_php et fonction phpinfo ;
- PHP Foundation, « Today's PHP Security Release, and How We're Strengthening PHP Security », 21 octobre 2026 ;
- CERT FR, alerte
CERTFR-2026-ALE-014et avisCERTFR-2026-AVI-1359, 21 octobre 2026 ; - CISA, « Critical Vulnerabilities in PHP Require Immediate Patching », 21 octobre 2026, et catalogue des failles exploitées, version du 21 octobre 2026 ;
- Ubuntu, avis
USN-8948-1etUSN-8948-2, 21 octobre 2026, et page sur l'obtention des correctifs ; - Debian, avis
DSA-6574-1etDLA-4848-1, FAQ de sécurité et manuel d'apt-get; - Red Hat, appliquer les mises à jour de paquets, et dnf, référence des commandes ;
- Docker Hub, image officielle php, dates des étiquettes relevées le 22 octobre 2026 ;
- OVHcloud, blog pour les serveurs Bare Metal et VPS et page d'état de l'hébergement web, 21 octobre 2026 ;
- o2switch, page d'état, message du 22 octobre 2026 sur les versions de PHP ;
- Infomaniak, page d'état dédiée, 21 et 22 octobre 2026 ;
- Hostinger, « Hostinger deploys protections against php2shell PHP vulnerabilities », mis à jour le 22 octobre 2026 ;
- LWS, « Failles critiques dans PHP : ce que LWS met en place pour protéger vos sites », 22 octobre 2026 ;
- IONOS, actualité du 22 octobre 2026 et page d'état ;
- Scaleway, page d'état, 21 et 22 octobre 2026 ;
- PlanetHoster, blog et site, aucune communication sur la faille le 22 octobre 2026 ;
- Microsoft, conseils de mise à jour pour PHP2Shell, 21 octobre 2026 ;
- WordPress.org, « Critical PHP Security Release », 21 octobre 2026, prérequis, écran Santé du site et FAQ « My site was hacked » ;
- WordPress.org, notes des versions de sécurité de 2026, relevées dans la rubrique Security, sauf 6.9.4, classée dans la rubrique Releases : 6.9.2 et 6.9.4 en mars, 7.0.2 en juillet, 7.0.3 et 7.0.4 en août, 7.1.1 et 7.1.2 en septembre, 7.1.3 en octobre ;
- WordPress, avis GitHub
GHSA-ff9f-jf42-662q(CVE-2026-63030),GHSA-fpp7-x2x2-2mjf(CVE-2026-60137),GHSA-7hp8-65ch-5whp(CVE-2026-87902),GHSA-52p2-r8wf-jcrf(CVE-2026-64638) etGHSA-8vr3-7mxf-gx8w(CVE-2026-65640) ; - WordPress.org, dernière version proposée par l'API des mises à jour, 7.1.3 le 22 octobre 2026, et documentation des mises à jour automatiques du cœur et des extensions et des thèmes ;
- WordPress, traduction française officielle de l'administration, et code des écrans Mises à jour, Extensions et Santé du site, libellés relevés le 22 octobre 2026 ;
- Patchstack, statistiques 2026 de sa base des failles WordPress, relevées le 22 octobre 2026 ;
- CISA, même catalogue des failles exploitées : entrées WordPress Core du 21 juillet 2026 (
CVE-2026-63030,CVE-2026-60137) et du 25 septembre 2026 (CVE-2026-87902) ; - Cybermalveillance.gouv.fr, AlerteCyber « Failles de sécurité critiques dans WordPress », 23 juillet 2026 ;
- PrestaShop, « Critical PHP security updates: what PrestaShop users need to know », 21 octobre 2026 ;
- php2shell.com, site des chercheurs, et Wiz, analyse technique, 21 octobre 2026 ;
- Amazon, blog sécurité AWS, 21 octobre 2026 ;
- Cloudflare, « Cloudflare deploys protections against php2shell vulnerability », 21 octobre 2026 ;
- W3Techs, part de PHP parmi les langages serveur, 22 octobre 2026 ;
- Google Search Central, dépannage des erreurs d'exploration, mise à jour du 21 décembre 2025, et désactiver temporairement un site, mise à jour du 31 décembre 2025 ;
- Aide Search Console, rapport sur les problèmes de sécurité et rapport Statistiques sur l'exploration ;
- Cybermalveillance.gouv.fr, fiche réflexe « Piratage d'un système informatique professionnel, que faire ? » ;
- Règlement général sur la protection des données, article 33, sur le portail du droit de l'Union européenne ; la page de la CNIL sur les violations de données était en maintenance le 22 octobre 2026.