Faille PHP2Shell : votre site est-il exposé ? Le guide de réaction pour les PME

Mercredi 21 octobre 2026, des sites de préfectures, certaines rubriques du portail des impôts et le site d’alertes de Météo-France sont passés en maintenance, selon Journal du Coin. Ces coupures étaient préventives : aucun des sites concernés n’avait signalé d’intrusion. En cause, deux failles critiques du langage PHP, surnommées PHP2Shell, qui permettent à un attaquant d’exécuter du code sur un serveur sans même s’authentifier.

Pour une PME, la question n’est pas de savoir si elle ressemble à une préfecture, mais si son site vitrine, sa boutique en ligne ou son extranet tourne sur PHP, comme près de sept sites sur dix parmi ceux dont le langage serveur est connu, d’après W3Techs. Cet article fait le point sur ce qui est établi, sur ce qui est exagéré, et sur ce qu’il faut faire aujourd’hui selon votre type d’hébergement. Il sera mis à jour au fil des alertes officielles ; dernière vérification des sources : 25 octobre 2026.

L’essentiel à retenir

• PHP2Shell désigne deux failles, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4.0), qui permettent une exécution de code à distance sans authentification. Elles sont corrigées depuis le 21 octobre dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
• Le défaut se trouve dans PHP lui-même, pas dans WordPress ou ses extensions : mettre à jour votre CMS ne suffit pas. Seul celui qui gère le serveur (votre hébergeur ou votre prestataire) peut appliquer le correctif.
• En hébergement mutualisé, c’est l’hébergeur qui corrige. Sur un VPS ou un serveur dédié, c’est vous ou votre prestataire, et il faut aussi redémarrer les services PHP.
• Pour PHP 8.1 et les versions antérieures, il n’existe pas de version officielle corrigée : il faut un paquet rétroporté par votre distribution ou un éditeur LTS, ou migrer vers une branche supportée.
• Des tentatives d’exploitation sont rapportées, mais nous n’avons pas trouvé de compromission réussie confirmée publiquement. Ni alarmisme, ni minimisation : la fenêtre d’action est courte.
• Si vous ne pouvez pas mettre à jour rapidement, les autorités recommandent d’isoler ou de mettre hors ligne le système concerné ; aucun réglage ne remplace complètement la mise à jour.

PHP2Shell : ce qui s’est passé, en bref

PHP2Shell regroupe deux vulnérabilités du moteur PHP, toutes deux notées 9,2 par l’équipe PHP selon l’avis de sécurité publié sur php.net :

• CVE-2026-109618 : exécution de code à distance par corruption de mémoire lorsque PHP manque de mémoire pendant le traitement d’une requête. Selon Huntress, qui rapporte les informations de PHP, une exécution de code non authentifiée a été validée sur Apache mod_php avec les paramètres par défaut.
• CVE-2026-109619 : exécution de code à distance par un « état global périmé » : des données internes propres à une requête survivent à la libération de leur mémoire, et la requête suivante traitée par le même processus peut les exploiter.

La chronologie, d’après PHP, Huntress, le CERT-FR et la CISA :

1. 20 octobre. Des détails fuitent avant la date prévue : un message publié sur Hacker News, retiré mais largement capturé, annonce deux failles critiques. watchTowr confirme la fuite. PHP annonce alors une version d’urgence pour le lendemain à 14 h UTC, un jour avant l’embargo initial.
2. 21 octobre. PHP publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, en début d’après-midi (la publication était annoncée pour 14 h UTC, soit 16 h à Paris). Plusieurs administrations européennes coupent des sites par précaution.
3. 22 octobre. Le CERT-FR met à jour son alerte : il a connaissance de preuves de concept, « pour des déploiements spécifiques de PHP ».
4. 23 octobre. PHP publie un avis informatif sur la fonction de suivi de progression des envois de fichiers (session upload progress) : il recommande de la désactiver jusqu’à la prochaine version de correction, pour se protéger d’un vecteur d’exécution de code jugé improbable, qui exige une combinaison inhabituelle de configuration et de code. La CISA révise son alerte le même jour.

Qui est concerné ? Les versions de PHP touchées et corrigées

Toute installation PHP qui sert des requêtes web est concernée, quel que soit le mode d’exécution : Apache avec mod_php (risque maximal selon PHP), PHP-FPM, php-cgi, FrankenPHP ou LiteSpeed, d’après la CISA. Le tableau ci-dessous reprend la liste du CERT-FR et les précisions de PHP.

Deux précisions. D’abord, les sources divergent sur la borne basse : le CERT-FR liste toutes les versions 5.x, 7.x, 8.0.x et 8.1.x, alors que l’article d’OVHcloud parle des versions antérieures à 7.4 comme sans correctif prévu. Retenez la règle prudente : toute branche non listée comme corrigée est à traiter comme vulnérable. Ensuite, certaines distributions Linux rétroportent les correctifs sur d’anciens paquets : un numéro de version ancien ne prouve donc pas qu’un serveur est exposé, et un numéro récent ne remplace pas la vérification du correctif (voir plus bas).

Le risque réel : ce qui est confirmé, ce qui est exagéré

Le sujet est dramatisé dans la presse grand public. Voici ce qu’on peut affirmer, ce qui relève de la prévision, et ce qui est une estimation.

Les sources de ce tableau : l’avis de PHP, l’alerte du CERT-FR, l’alerte de la CISA, la FAQ de watchTowr, l’analyse de Huntress, l’article de SecurityWeek, l’analyse de CybelAngel et la dépêche de The National News Desk. Notez que l’exploitation observée par watchTowr vient de ses propres pièges (honeypots) : c’est une source unique à recouper. La CISA n’avait pas observé d’exploitation réussie à la date de sa publication.

Le point important est ailleurs : le délai entre le correctif et les premières tentatives d’attaque se compte en heures, pas en semaines. L’ANSSI note dans son panorama de la cybermenace 2025 que l’IA abaisse le seuil d’entrée des attaques et que les vulnérabilités progressent d’environ 18 % par an. Notre analyse sur les cyberattaques automatisées par IA et notre pilier IA en cybersécurité PME : panorama complet des technologies 2026 expliquent comment cette accélération change la défense. Pour la logique générale d’une faille que l’on ne peut pas corriger immédiatement, voir aussi nos articles sur les vulnérabilités zero-day et le patch management.

Pourquoi des préfectures et des services publics ont coupé leurs sites ?

En France, selon Journal du Coin, les sites de plusieurs préfectures (dont la préfecture de police), certaines rubriques du portail des impôts, le site du ministère de l’Économie, le site d’alertes de Météo-France et celui des Échos affichaient un message de maintenance le 21 octobre. L’article attribue la décision du ministère de l’Intérieur à une demande de l’ANSSI ; Connexion France rapporte seulement que le ministère a indiqué que les sites avaient été mis hors ligne le temps d’appliquer des mesures de sécurité. Aucun des sites coupés n’a signalé d’intrusion : l’arrêt était volontaire et préventif.

Les autres pays ont réagi de la même façon. Le gouvernement néerlandais a annoncé que plusieurs sites publics (Overheid.nl, MijnOverheid.nl, DigiD) étaient mis hors ligne par précaution. Son centre de cybersécurité (NCSC) conseille aux propriétaires de sites PHP de faire leur propre analyse de risque et d’envisager de couper leur site, puis d’appliquer les correctifs dès qu’ils sont disponibles. Rijksoverheid.nl n’était pas touché, car il n’utilise pas PHP. Selon The National News Desk, des sites ont aussi été coupés en Finlande et en Belgique. La CISA conseille de mettre hors ligne les systèmes qui ne peuvent pas être mis à jour rapidement, et, selon la même dépêche, le FBI et la NSA aussi.

Que retenir pour une PME ? La coupure préventive est une décision de gestion du risque, pas un réflexe obligatoire. Pour un site vitrine de quelques pages, une page de maintenance de quelques heures coûte peu. Pour une boutique en ligne ou un service client, le calcul est différent : il faut comparer le coût d’une interruption à celui d’une intrusion. L’essentiel est de décider consciemment, avec votre hébergeur, plutôt que de laisser un site vulnérable ouvert par défaut.

WordPress, PrestaShop, Joomla : pourquoi mettre à jour le CMS ne suffit pas ?

Un CMS comme WordPress, PrestaShop, Joomla ou Drupal est un programme écrit en PHP, exécuté par l’interpréteur PHP du serveur. Les failles de PHP2Shell sont dans cet interpréteur, pas dans le CMS. Mettre à jour WordPress, un thème ou une extension ne les corrige donc pas : selon Newsweek, Drupal indique que la mise à jour de PHP est la seule atténuation complète. La mise à jour doit être faite sur le serveur, par la personne qui l’administre.

L’ampleur du parc concerné est considérable. Au 25 octobre 2026, W3Techs indique que WordPress est utilisé par 39,6 % de tous les sites web, et que 69,2 % des sites dont le langage serveur est connu utilisent PHP. Parmi ces sites PHP, 65,5 % tournent sous PHP 8, 26,8 % sous PHP 7 et 7,7 % sous PHP 5. Attention : la catégorie « PHP 8 » inclut les versions 8.0 et 8.1, qui ne sont plus supportées. Au moins un site PHP sur trois (34,6 %) utilise une branche 7 ou antérieure, sans version corrigée officielle. Ces chiffres ne mesurent que les versions détectables de l’extérieur.

C’est un rappel concret des risques décrits dans notre pilier sur la sécurité des applications web PME : un composant d’infrastructure en fin de vie compromet un site même parfaitement entretenu côté contenu. Si vous vendez en ligne, notre guide Cybersécurité pour commerçants et artisans détaille la protection de la boutique et des paiements.

Comment vérifier votre version de PHP et la réponse de votre hébergeur ?

Comptez une demi-heure pour un petit site. L’objectif : savoir quelle version PHP sert réellement votre site et si votre hébergeur a déployé le correctif.

1. Inventoriez vos sites et applications. Site vitrine, boutique, extranet, intranet, outil de prise de rendez-vous, sites oubliés d’anciens prestataires. La CISA demande de recenser aussi les logiciels tiers qui embarquent PHP.
2. Identifiez qui administre le serveur. Hébergement mutualisé : votre hébergeur. VPS ou dédié : vous ou votre prestataire. Application livrée par un éditeur : l’éditeur.
3. Relevez la version de PHP. Sous WordPress, ouvrez Outils, Santé du site, onglet Info, rubrique Serveur. Sinon, consultez la rubrique PHP du panneau de votre hébergeur. Sur un VPS, la commande php -v donne la version en ligne de commande ; OVHcloud rappelle de contrôler aussi la version réellement utilisée par le site web, qui peut différer.
4. Comparez avec le tableau ci-dessus. Si votre version est antérieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou si elle est en fin de vie, considérez le site comme exposé tant qu’un correctif n’est pas confirmé.
5. Demandez une confirmation écrite à l’hébergeur. Posez une question précise : « Les failles CVE-2026-109618 et CVE-2026-109619 sont-elles corrigées sur mon offre, à quelle date, et avec quelle version ou quel paquet ? ». Cette précision compte à cause des correctifs rétroportés, où le numéro de version ne change pas.
6. Redémarrez ou faites redémarrer les services PHP après la mise à jour. watchTowr recommande de redémarrer tous les processus PHP, et OVHcloud signale que cette étape est souvent oubliée.
7. Conservez la preuve. La confirmation de l’hébergeur et la date de correction serviront à votre assureur, à vos clients et à votre propre suivi de conformité.

Pour aller plus loin dans la détection d’actifs et de vulnérabilités sur l’ensemble de votre parc, voir notre comparatif Tenable, Qualys et Rapid7 et notre article sur le pentest pour PME.

Que faire selon votre type d’hébergement ?

Le bon réflexe dépend de qui contrôle PHP. Le tableau résume les cas courants pour une PME.

Si un prestataire gère votre site, c’est le moment de lui demander une réponse chiffrée et datée. Notre guide Comment choisir un prestataire informatique de confiance et notre article sur la gestion des risques tiers proposent une grille pour évaluer sa réactivité. L’épisode illustre aussi les attaques par la chaîne d’approvisionnement : votre sécurité dépend d’un composant que vous ne gérez pas. Pour les équipes qui développent leurs propres applications et images, notre article sur le DevSecOps explique comment intégrer ces mises à jour aux pipelines.

Si vous ne pouvez pas mettre à jour tout de suite : contournements et limites

Un point d’abord : selon la FAQ de watchTowr, PHP indique qu’aucun changement de configuration ne neutralise complètement ces failles. Les mesures ci-dessous réduisent le risque, elles ne le suppriment pas.

• Désactiver le suivi de progression des envois. PHP recommande session.upload_progress.enabled=0 puis le redémarrage de tous les processus. Cette mesure bloque les chemins confirmés, pas les autres variantes. Le CERT-FR précise qu’elle ne réduit la surface d’attaque que pour CVE-2026-109619, et que ces contournements n’ont pas été qualifiés par l’agence. Pour PHP-FPM, le paramètre se règle avec php_admin_flag[session.upload_progress.enabled].
• Bloquer les requêtes multipart. Le CERT-FR cite le blocage, par un pare-feu applicatif, des requêtes HTTP dont le type de contenu est multipart, ou à défaut leur supervision. À n’envisager que si votre site n’a pas de formulaire d’envoi de fichiers.
• Un pare-feu applicatif en protection temporaire. La CISA le mentionne comme protection intermédiaire, pas comme solution.
• Isoler ou mettre hors ligne. C’est la recommandation de la CISA pour les systèmes qui ne peuvent pas être mis à jour immédiatement ou qui utilisent encore PHP 8.1 ou une version antérieure, et celle du CERT-FR : isoler les équipements concernés puis migrer vers une version maintenue.

Autre élément à connaître : OVHcloud mentionne aussi des réglages de mémoire pour CVE-2026-109618, à manier avec prudence car ils peuvent saturer le serveur. Ne les appliquez que sur les conseils de votre prestataire, et uniquement en attendant la mise à jour.

Votre site a-t-il déjà été visité ? Signes de compromission et premiers gestes

Appliquer le correctif empêche une nouvelle intrusion, mais n’efface pas une porte dérobée déjà posée. Pour un site resté exposé depuis le 21 octobre, quelques contrôles s’imposent. Selon Huntress, aucun indicateur de compromission n’était confirmé au moment de son analyse, et les règles de détection seront publiées au fil des analyses techniques.

• Surveillez les processus. Huntress recommande d’alerter sur les processus de serveur web (php-fpm, php-cgi, apache2, httpd) qui lancent un interpréteur de commandes, un outil de téléchargement ou un outil réseau (curl, wget, nc), ou qui exécutent des commandes de reconnaissance comme whoami ou uname -a.
• Cherchez des traces d’intrusion. Fichiers PHP récents ou inconnus dans la racine web (webshells), tâches planifiées ajoutées, nouveaux comptes, modifications de fichiers du CMS.
• Conservez les journaux du serveur web et de PHP avant tout nettoyage : ils serviront à l’enquête et à votre déclaration éventuelle.
• Changez les secrets si un doute existe. Selon Wiz, cité par Huntress et par Newsweek, une voie distincte de fuite de mémoire pourrait exposer des mots de passe, des jetons, des clés d’API ou des certificats. Renouvelez les mots de passe de base de données et d’administration, les clés d’API et les clés de sécurité du CMS, et activez la double authentification sur les comptes d’administration.

En cas de signe suspect, suivez notre guide Mon site internet a été piraté : comment le savoir et que faire, notre plan de réponse à incident et les 24 premières heures. Si des données personnelles ont pu être exposées, une notification à la CNIL sous 72 heures peut s’imposer : le pilier Qui prévenir en cas de cyberattaque détaille les démarches. Un serveur compromis sert aussi souvent à miner des cryptomonnaies ou à lancer d’autres attaques : voir notre article sur le cryptojacking. Pour renouveler vos accès proprement, consultez nos guides sur les gestionnaires de mots de passe et la MFA en PME. Enfin, vérifiez vos sauvegardes avec la règle 3-2-1.

Souveraineté : choisir un hébergeur qui corrige vite et vous le dit

Soyons précis : cette faille n’a rien à voir avec le CLOUD Act. Elle touche un logiciel libre, quel que soit le pays de l’hébergeur ou de l’éditeur. En revanche, l’épisode rappelle une réalité : une PME dépend de celui qui opère ses serveurs pour sa réactivité, ses délais de correction et sa transparence. C’est un critère de choix au même titre que le lieu d’hébergement.

Avant de choisir ou de renouveler un hébergeur, posez-lui ces cinq questions :

1. Dans quel délai appliquez-vous un correctif critique de PHP sur mon offre, et comment me prévenez-vous ?
2. Quelles versions de PHP proposez-vous, et quelle est leur date de fin de support ?
3. Puis-je changer de version de PHP facilement et tester avant de basculer ?
4. Où mes données sont-elles stockées, et quel droit s’applique à votre société et à vos sous-traitants ?
5. Quelles sauvegardes sont incluses, et comment restaure-t-on après un incident ?

À titre d’exemple de communication utile, OVHcloud, hébergeur français, a publié un avis détaillé distinguant ce qu’il corrige lui-même (hébergement mutualisé, WebCloud) et ce que le client doit faire (VPS, serveurs dédiés). Cet exemple ne vaut pas recommandation de délai de correction : nous n’avons pas de mesure comparée de la rapidité des hébergeurs. Un hébergeur européen n’est pas automatiquement meilleur, et un hébergeur non européen n’est pas automatiquement moins réactif : la preuve se fait sur des engagements écrits. Pour la dimension de souveraineté et de droit applicable, voir notre guide de la cybersécurité souveraine anti-CLOUD Act et notre pilier sur la sécurité cloud pour PME. L’hébergement compte aussi pour votre assureur : voir pourquoi votre assureur cyber va vous demander où est hébergé votre site.

Obligations, assurance, NIS2 : le poids d’une faille connue non corrigée

Le RGPD exige, à son article 32, des mesures de sécurité appropriées « compte tenu de l’état des connaissances ». À notre analyse, laisser en ligne pendant des semaines un site exposé à une faille critique publiquement documentée est le type de manquement qu’une autorité de contrôle ou un assureur peut relever en cas d’incident. Notre guide RGPD et cybersécurité : les obligations des PME en 2026 détaille ces exigences, et l’article sur la responsabilité du dirigeant précise ce que dit la loi. Côté assurance, relisez les exclusions de votre contrat avec notre article pourquoi votre assureur refuse parfois d’indemniser et notre pilier sur l’assurance cyber pour PME.

La directive NIS2 cite la gestion et la divulgation des vulnérabilités parmi les mesures de son article 21. Elle vise en principe les entités de taille moyenne ou grande des secteurs concernés, à partir de 50 salariés, comme l’explique notre guide de mise en conformité NIS2. À notre connaissance, la loi française de transposition n’est pas adoptée à ce jour : Leto rapporte que son examen à l’Assemblée nationale a été retiré de l’ordre du jour des 7 et 9 octobre, sans nouvelle date. NIS2 reste un bon référentiel : notre pilier sur les nouvelles obligations réglementaires de cybersécurité 2026 suit le calendrier.

Questions fréquentes sur la faille PHP2Shell

Qu’est-ce que la faille PHP2Shell ?

PHP2Shell désigne deux vulnérabilités du moteur PHP, CVE-2026-109618 et CVE-2026-109619, qui permettent à un attaquant d’exécuter du code à distance sur un serveur sans authentification. Elles sont notées 9,2 sur 10 (CVSS v4.0) et corrigées depuis le 21 octobre 2026 dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12.

Mon site WordPress est-il vulnérable ?

Cela dépend de la version de PHP sur le serveur qui l’héberge, pas de WordPress. Si cette version est antérieure aux versions corrigées, ou si elle est en fin de vie, le site est exposé tant que l’hébergeur n’a pas déployé le correctif. Vérifiez la version dans Outils, Santé du site, Info, Serveur, et demandez une confirmation écrite à votre hébergeur.

Faut-il couper mon site ?

Pas systématiquement. La CISA recommande de mettre hors ligne les systèmes PHP qui ne peuvent pas être mis à jour immédiatement ou qui utilisent encore PHP 8.1 ou une version antérieure. Le centre de cybersécurité néerlandais conseille de faire sa propre analyse de risque. Si votre hébergeur confirme le correctif, il n’y a pas lieu de couper.

Comment savoir si mon hébergeur a corrigé la faille ?

Demandez-lui par écrit si CVE-2026-109618 et CVE-2026-109619 sont corrigées sur votre offre, à quelle date et avec quelle version ou quel paquet. Ne vous fiez pas uniquement au numéro de version : certaines distributions rétroportent les correctifs sans changer ce numéro.

PHP 8.1 reçoit-il un correctif ?

PHP n’a pas publié de version officielle pour les branches 8.1 et antérieures, qui ne sont plus supportées. Des paquets rétroportés peuvent exister chez les distributions et les éditeurs LTS, et PHP mentionne des correctifs source minimaux, mais Huntress ne peut pas évaluer leur efficacité. La solution durable est de migrer vers une branche supportée.

Mon site a-t-il pu être piraté avant le correctif ?

C’est possible si le site est resté exposé depuis le 21 octobre, même si nous n’avons pas trouvé de compromission réussie confirmée publiquement. Contrôlez les processus de serveur web, les fichiers PHP récents ou inconnus, les tâches planifiées et les comptes, conservez les journaux et renouvelez les secrets en cas de doute.

Les contournements suffisent-ils si je ne peux pas mettre à jour ?

Non. Désactiver session.upload_progress.enabled bloque les chemins confirmés mais pas les autres variantes, et ne réduit la surface d’attaque que pour CVE-2026-109619 selon le CERT-FR. Seule la mise à jour est complète. En attendant, isolez ou mettez hors ligne le site si possible.

Conclusion

PHP2Shell est une vraie faille critique, corrigée rapidement, et dont l’impact tient moins à sa technique qu’à son ampleur : tout site PHP dont le serveur n’est pas à jour est concerné, et la mise à jour ne dépend pas du CMS mais de celui qui administre le serveur. Les faits établis sont solides (exécution de code sans authentification, versions corrigées, absence de correctif officiel pour 8.1 et antérieures). Les chiffres spectaculaires et les prévisions d’attaques de masse sont à lire comme des estimations ou des prévisions, et non comme des constats.

La conduite à tenir tient en quatre gestes : savoir qui administre votre serveur, vérifier la version de PHP, obtenir la confirmation écrite du correctif, et surveiller les signes d’intrusion. Cet épisode s’inscrit dans votre stratégie globale, présentée dans notre guide complet de la cybersécurité PME 2026. Pour mesurer rapidement où vous en êtes sur la gestion des mises à jour et de vos prestataires, l’audit cybersécurité PME de SIAC Media est le point de départ le plus simple, et notre modèle d’audit avec checklist PDF vous permet de le faire vous-même.