Faille PHP critique PHP2Shell : ce que votre entreprise doit faire

Sommaire

• L’essentiel
• Que s’est-il passé avec PHP les 20 et 21 octobre 2026 ?
• Où en est-on au 24 octobre 2026 ?
• Pourquoi cette faille PHP est-elle plus grave que d’habitude ?
• Votre site est-il concerné ?
• Que faire dès aujourd’hui, concrètement ?
• Un site statique est-il à l’abri ? L’exemple de Nodeor Conseil
• Que retenir pour la suite ?
• FAQ
• Faire le point sur votre site

---

Mis à jour le 24 octobre 2026 : premières tentatives d’attaque dès le 17 octobre, réponse des hébergeurs français, troisième faille annoncée.

Mardi 20 octobre, des détails sur deux failles critiques de PHP ont fuité sur Internet avant leur publication officielle. Le lendemain, l’équipe de PHP a publié en urgence les correctifs. Si votre site tourne sous WordPress, Drupal, Joomla, PrestaShop ou n’importe quel outil écrit en PHP, il est concerné tant que votre hébergeur n’a pas installé la nouvelle version.

La réponse courte : la faille PHP baptisée « PHP2Shell » (références CVE-2026-109618 et CVE-2026-109619) peut permettre à un attaquant de prendre le contrôle d’un serveur à distance, sans mot de passe. La seule vraie protection est la mise à jour de PHP, qui se fait chez l’hébergeur, pas dans WordPress. Voici ce qui s’est passé, comment savoir si vous êtes exposé, et les questions précises à poser à votre prestataire cette semaine.

L’essentiel

• Deux failles critiques dans le moteur PHP lui-même, notées 9,2 sur 10 par l’équipe de sécurité de PHP.
• Presque tous les sites en PHP sont concernés : selon Wiz Research, toutes les versions depuis PHP 5.4 sont touchées par au moins une des deux failles.
• Les correctifs existent depuis le 21 octobre 2026 : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Les attaquants sont déjà à l’œuvre : Amazon a vu une première tentative dès le 17 octobre, quatre jours avant les correctifs, et un réseau de machines piratées de type Mirai s’y est mis depuis. Au 23 octobre, aucune intrusion réussie n’était confirmée publiquement.
• Les grands hébergeurs français ont corrigé : o2switch, OVHcloud, Infomaniak et Hostinger ont mis à jour leurs offres mutualisées entre le 21 et le 22 octobre. Les VPS et serveurs dédiés restent à la charge de leur propriétaire.
• Votre action : obtenir de votre hébergeur la confirmation écrite que PHP est à jour sur tous vos sites, y compris les anciens et les sites de test.

Que s’est-il passé avec PHP les 20 et 21 octobre 2026 ?

Deux failles graves de PHP ont été rendues publiques plus tôt que prévu, à la suite d’une fuite, et les correctifs sont sortis le 21 octobre 2026. Entre les deux, les attaquants ont eu une longueur d’avance sur une partie des hébergeurs.

Dans un fonctionnement normal, une faille de cette ampleur suit un circuit discret. Les chercheurs préviennent l’équipe de PHP, qui prépare le correctif, le transmet en avance aux distributions Linux et aux grands fournisseurs, puis tout le monde publie le même jour. Les hébergeurs ont alors le correctif en main au moment où les attaquants découvrent la faille.

Cette fois, le circuit a été court-circuité. D’après Huntress, un message publié le matin du 20 octobre sur un forum technique très suivi annonçait deux failles critiques à venir. Le message a été retiré, mais des captures d’écran ont circulé. L’équipe de PHP a alors avancé sa publication : les versions corrigées sont sorties le 21 octobre, et les analyses techniques détaillées des chercheurs ont suivi le soir même.

Les deux failles portent les références CVE-2026-109618 et CVE-2026-109619. Sans entrer dans le détail, elles exploitent la façon dont PHP gère sa mémoire quand une requête tourne mal. Une requête piégée peut laisser derrière elle des données mal nettoyées, qu’une requête suivante réutilise. C’est cette brèche qui ouvre la porte à l’exécution de commandes sur le serveur.

Où en est-on au 24 octobre 2026 ?

Les correctifs sont largement déployés chez les hébergeurs, les tentatives d’attaque sont massives mais aucune intrusion réussie n’était confirmée au 23 octobre, et une troisième faille, moins grave, attend son correctif.

Date	Ce qui s’est passé
Samedi 17 octobre	Amazon repère une première tentative d’exploitation sur ses serveurs pièges, quatre jours avant les correctifs (source)
Mardi 20 octobre	Fuite des détails sur un forum technique, l’équipe de PHP avance sa publication
Mercredi 21 octobre, 12h30	Par précaution, plusieurs sites publics passent en maintenance, dont ceux de la CNIL et des préfectures (Selectra)
Mercredi 21 octobre, 15h40	Publication des versions corrigées de PHP
21 et 22 octobre	Mise à jour des offres mutualisées chez les grands hébergeurs français
Vendredi 23 octobre	Une troisième faille liée, jugée moins probable à exploiter, est annoncée ; son correctif suivra la prochaine version normale de PHP (Techaeris)

Côté attaques, le tableau s’est précisé. Sophos a observé des tentatives visant à installer une variante du botnet Mirai, un réseau de machines piratées utilisé pour d’autres attaques. VulnCheck a montré qu’une attaque reste possible sur un serveur configuré selon les recommandations habituelles de production. Wordfence indiquait toutefois le 23 octobre que les attaques se poursuivaient « sans aucune compromission connue jusqu’à présent » (SecurityWeek).

Le retard reste énorme à l’échelle mondiale : selon Censys, plus de 34 millions de services PHP accessibles sur Internet tournaient encore sur une version vulnérable le 23 octobre. Les sites hébergés en mutualisé chez un grand hébergeur sont, pour la plupart, déjà protégés. Ceux qui tournent sur un serveur géré par une petite structure, ou oublié depuis des années, beaucoup moins.

Pourquoi cette faille PHP est-elle plus grave que d’habitude ?

Parce qu’elle se trouve dans le moteur qui fait tourner le site, et non dans une extension, et parce qu’elle peut être exploitée sans identifiant. Un site à jour côté WordPress reste vulnérable si PHP ne l’est pas.

La plupart des alertes de sécurité qui touchent les sites d’entreprise concernent une extension WordPress ou un thème. On met à jour l’extension, et le problème est réglé. Ici, la faille est un étage plus bas. PHP est le langage qui exécute WordPress, Drupal, Joomla, Magento ou Laravel. Si le moteur est vulnérable, tout ce qui tourne dessus l’est aussi, quelle que soit la qualité du site.

Trois éléments expliquent le niveau d’alerte :

1. L’attaque se fait sans compte ni mot de passe. Selon l’équipe de PHP, citée par Huntress, une simple requête peut déclencher l’attaque sur certaines configurations, avant même que le code du site ne s’exécute.
2. Le périmètre est immense. L’équipe de PHP indique que toutes les installations qui répondent à des requêtes web sont à risque, quel que soit le mode de fonctionnement du serveur (PHP-FPM, Apache, LiteSpeed et d’autres).
3. Les données sensibles sont exposées. Wiz Research a montré, d’après Patchstack, que la mémoire de PHP pouvait être lue, avec à la clé des mots de passe, des jetons d’accès ou des clés de services tiers (paiement, envoi d’e-mails, CRM).

Les autorités ont réagi vite. Le NCSC britannique, l’équivalent de l’ANSSI au Royaume-Uni, demande aux organisations de « prendre des mesures immédiates » et va jusqu’à recommander de couper un système s’il ne peut être ni mis à jour ni protégé rapidement.

Les signalements d’attaques ont d’abord divergé : Patchstack faisait état d’exploitations signalées par des hébergeurs partenaires, Huntress n’en voyait pas chez ses clients le 21 octobre. La conclusion pratique n’a jamais changé : on n’attend pas d’en savoir plus pour mettre à jour.

Votre site est-il concerné ?

Votre site est concerné s’il fonctionne avec PHP et que la version installée est antérieure aux correctifs du 21 octobre 2026. C’est le cas de la grande majorité des sites WordPress en France.

Le tableau ci-dessous donne, pour chaque branche de PHP, la version minimale à atteindre.

Votre version de PHP	Version corrigée	Situation
PHP 8.5	8.5.12 ou plus	Mise à jour simple chez l’hébergeur
PHP 8.4	8.4.27 ou plus	Mise à jour simple chez l’hébergeur
PHP 8.3	8.3.36 ou plus	Mise à jour simple chez l’hébergeur
PHP 8.2	8.2.35 ou plus	Mise à jour simple chez l’hébergeur
PHP 8.1 et plus ancien	Aucune version officielle	Correctif de l’hébergeur ou changement de version, à tester avant

Attention, un numéro de version plus ancien ne veut pas toujours dire « vulnérable ». Certains hébergeurs, comme ceux qui utilisent CloudLinux (o2switch par exemple), recompilent PHP avec le correctif sans changer le numéro affiché. C’est aussi ce qui permet de protéger les vieilles versions 7.4, 8.0 ou 8.1. Seule une confirmation de l’hébergeur fait foi.

Pour connaître votre version, trois chemins existent. Dans l’administration de WordPress, l’outil « Santé du site », onglet « Infos », section « Serveur », affiche la version de PHP. Dans l’espace client de la plupart des hébergeurs, elle apparaît dans les réglages de l’hébergement. Et si vous avez un prestataire, il doit pouvoir vous la donner en quelques minutes.

Pensez aussi à tout ce qui n’est pas votre site principal. Une ancienne version du site gardée « au cas où », un site de test, un sous-domaine pour une campagne passée, un outil interne en PHP : chacun de ces éléments est une porte d’entrée possible, souvent oubliée et rarement mise à jour. Le NCSC insiste justement sur cet inventaire complet.

Que faire dès aujourd’hui, concrètement ?

Faites mettre PHP à jour par votre hébergeur ou votre prestataire, sur tous vos sites, et demandez-en une confirmation écrite. Les réglages provisoires ne remplacent pas cette mise à jour.

Les questions à poser à votre hébergeur ou à votre agence

Un message court suffit. Voici ce qu’il doit contenir :

• Quelle version exacte de PHP tourne sur chacun de nos sites, y compris les sites de test et les anciens sites encore en ligne ?
• Le correctif du 21 octobre 2026 contre les failles CVE-2026-109618 et CVE-2026-109619 est-il installé ? Si non, à quelle date le sera-t-il ?
• Si un site tourne encore en PHP 8.1 ou plus ancien, quel correctif appliquez-vous, ou quel est le plan de montée de version ?
• Avez-vous constaté des signes d’attaque sur nos sites depuis le 20 octobre ?

Sur un hébergement mutualisé, c’est l’hébergeur qui met à jour PHP pour tous ses clients. Les grands hébergeurs ont reçu les correctifs en avance : la mise à jour est souvent déjà faite, mais seule une réponse écrite vous le garantit. Sur un serveur dédié ou un VPS, c’est en revanche à vous ou à votre prestataire de l’installer.

Ce que les hébergeurs français ont déjà fait

Bonne nouvelle pour la plupart des entreprises : sur les offres mutualisées des grands hébergeurs, la mise à jour a été faite sans action de votre part.

Hébergeur	Offres mutualisées	À noter
o2switch	Corrigé le 21 octobre, de PHP 5.2 à 8.5	Suivi des envois de fichiers désactivé par défaut (blog o2switch)
OVHcloud	Corrigé le 21 octobre au soir, de PHP 7.4 à 8.5	VPS et serveurs dédiés : à votre charge
Infomaniak	Corrigé le 21 octobre, de PHP 7.4 à 8.5	Correctif appliqué aussi aux versions 7.4 à 8.1
Hostinger	Corrigé le 22 octobre au matin, de PHP 5.2 à 8.5	Hors VPS

Ces informations sont reprises du guide par hébergeur de Digital Corner et des annonces des hébergeurs. Si le vôtre n’y figure pas, ou si votre site tourne sur un VPS, posez-lui directement les questions ci-dessus.

Ce qu’il ne faut pas faire

Ne cherchez pas de solution miracle dans le répertoire des extensions WordPress. Patchstack met en garde contre les extensions de « correctif » et les bouts de code copiés-collés apparus depuis la fuite : ils ne sont pas vérifiés et peuvent casser un site. Aucune extension ne peut mettre à jour PHP.

Il existe des réglages provisoires, comme la désactivation de l’option session.upload_progress dans la configuration de PHP, que l’hébergeur peut appliquer en attendant la mise à jour. L’équipe de PHP le dit clairement : ces mesures « ne rendent pas une installation sûre ». Elles réduisent le risque pendant quelques heures, rien de plus. Ce même réglage est en revanche la mesure recommandée par l’équipe de PHP contre la troisième faille annoncée le 23 octobre, en attendant son correctif : demandez à votre hébergeur s’il l’a appliqué.

Si un doute existe sur une attaque passée

Patchstack liste quelques signaux à surveiller dans les journaux du serveur : des erreurs 500 à répétition, des erreurs de mémoire après des envois de fichiers inhabituels, des cookies de session anormalement longs, des redémarrages de PHP inexpliqués. Aucun de ces signes n’est une preuve. Mais s’ils apparaissent, la prudence impose de traiter le serveur comme compromis, et de changer les mots de passe et les clés qu’il contient : accès à l’administration, base de données, clés de paiement, de messagerie ou de CRM.

Pour aller plus loin sur les bonnes pratiques de fond, notre guide pour sécuriser un site WordPress en 10 étapes reprend la mise à jour, les sauvegardes et la gestion des accès.

Un site statique est-il à l’abri ? L’exemple de Nodeor Conseil

Un site statique n’exécute pas de PHP quand un visiteur charge une page : la faille PHP2Shell n’a donc rien à attaquer à ce niveau. C’est un argument concret pour certains sites vitrines.

Un site statique est un site dont toutes les pages sont fabriquées à l’avance, puis servies telles quelles au visiteur. Il n’y a pas de logiciel qui calcule la page à chaque visite, donc pas de moteur PHP exposé à Internet pour l’affichage du site.

C’est le choix que nous avons fait pour Nodeor Conseil, cabinet d’expertise comptable et de direction financière à Lyon. Le cabinet voulait un site rapide, crédible et sécurisé, sans dépendre d’un CMS lourd. Nous avons construit un site 100 % statique avec Astro, sans serveur applicatif : 34 pages générées, dont 14 articles d’expertise et 4 simulateurs financiers, avec une politique de sécurité stricte qui interdit tout script non prévu. Face à une alerte comme celle de cette semaine, ce type de site n’a pas de moteur PHP à mettre à jour en urgence.

Ce n’est pas pour autant la bonne réponse pour tout le monde. WordPress reste pertinent pour une entreprise qui publie beaucoup, gère des réservations ou une boutique, et veut une autonomie totale sur ses contenus. Le vrai sujet est de choisir en connaissance de cause, en intégrant la maintenance et la sécurité dans le calcul. Notre comparatif Astro ou WordPress en 2026 détaille ces arbitrages.

Une précaution reste valable même pour un site statique : vérifier qu’aucun élément en PHP ne traîne à côté, comme un formulaire maison, une ancienne version du site ou un sous-domaine oublié chez le même hébergeur.

Que retenir pour la suite ?

La sécurité d’un site ne s’arrête pas aux mises à jour de WordPress et des extensions. Le moteur, le serveur et les sites oubliés comptent autant, et une alerte comme celle-ci se règle en quelques heures quand les rôles sont clairs à l’avance.

Cet épisode met en lumière une question que beaucoup d’entreprises ne se posent qu’en pleine crise : qui, exactement, est responsable de la mise à jour de PHP sur mon site ? L’hébergeur, l’agence qui a créé le site, le prestataire de maintenance, ou personne ? Si la réponse n’est pas évidente pour vous aujourd’hui, c’est le premier point à régler, avant la prochaine alerte.

Trois habitudes simples réduisent nettement le risque :

• Tenir une liste à jour de tous vos sites et sous-domaines, avec pour chacun l’hébergeur, la technologie et la personne responsable des mises à jour.
• Supprimer ce qui ne sert plus. Un ancien site laissé en ligne est un risque sans bénéfice.
• Rester sur une version de PHP encore maintenue. Les sites bloqués sur PHP 8.1 ou plus ancien ne reçoivent plus de correctif officiel, et cette alerte le rappelle brutalement. PHP 8.2 suivra le 31 décembre 2026 : c’est le bon moment pour planifier le passage à PHP 8.4.

Pour une vue plus large des risques qui pèsent sur un site d’entreprise, notre article sur les principales menaces cyber pour un site professionnel en 2026 fait le tour des autres portes d’entrée.

FAQ

Mon site WordPress est-il concerné par la faille PHP2Shell ?

Oui, s’il tourne sur une version de PHP antérieure aux correctifs du 21 octobre 2026. La faille se trouve dans PHP lui-même, pas dans WordPress : un WordPress parfaitement à jour reste exposé tant que PHP ne l’est pas. Les chercheurs de Wiz ont d’ailleurs démontré l’attaque sur une installation WordPress récente.

Quelles versions de PHP corrigent la faille ?

Les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les versions 8.1 et plus anciennes ne reçoivent plus de mises à jour officielles : il faut soit un correctif fourni par l’hébergeur, soit une montée de version, à tester avant la mise en ligne.

Mon hébergeur a corrigé PHP : ai-je encore quelque chose à faire ?

Pour un hébergement mutualisé, l’essentiel est fait, mais demandez une confirmation écrite qui couvre tous vos sites, y compris les anciens et les sites de test. Sur un VPS ou un serveur dédié, la mise à jour reste à votre charge ou à celle de votre prestataire. Enfin, une troisième faille, moins grave, a été annoncée le 23 octobre : en attendant son correctif, l’équipe de PHP recommande de désactiver le suivi de progression des envois de fichiers, ce que plusieurs hébergeurs ont déjà fait.

Est-ce que je peux corriger la faille moi-même depuis WordPress ?

Non. Aucune extension WordPress ne met à jour PHP. La version de PHP se règle chez l’hébergeur, depuis votre espace client ou par son support. Patchstack déconseille aussi les extensions de « correctif » non officielles apparues depuis la fuite, qui ne sont pas vérifiées et peuvent casser un site.

Un site statique est-il exposé à cette faille ?

Un site statique bien construit n’exécute pas de PHP quand un visiteur charge une page : la faille n’a donc rien à attaquer à ce niveau. Il faut tout de même vérifier les éléments annexes hébergés à côté (formulaire en PHP, ancien site resté en ligne, sous-domaine oublié).

Comment savoir si mon site a déjà été attaqué ?

Patchstack cite plusieurs signaux : des requêtes d’envoi de fichiers inhabituelles suivies d’erreurs de mémoire, des erreurs 500 à répétition, des cookies de session anormalement longs ou des redémarrages inexpliqués de PHP. Ces signes ne prouvent rien à eux seuls. S’ils apparaissent, mettez PHP à jour, considérez le serveur comme potentiellement compromis et changez les mots de passe et clés qu’il contient.

Faire le point sur votre site

Vous ne savez pas quelle version de PHP fait tourner votre site, ni qui doit s’en occuper ? C’est exactement le genre de question que nous clarifions lors d’un audit de site. Si vous préférez en parler directement, réservez un appel de 20 minutes : nous regardons ensemble votre situation et les priorités à traiter.

Article rédigé le 22 octobre 2026 et mis à jour le 24 octobre, à partir des informations publiées par l’équipe de PHP, Huntress, Patchstack, le NCSC, Amazon, SecurityWeek et les hébergeurs cités. La situation évolue vite : vérifiez les annonces de votre hébergeur.