%20_%20ce%20qu%27il%20faut%20savoir%20et%20que%20faire%20.png)
Les failles PHP baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619) sont deux vulnérabilités critiques du moteur PHP qui permettent d'exécuter du code à distance sur un serveur, sans identifiant ni mot de passe. Corrigées le 21 octobre 2026, elles imposent de passer en PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, quel que soit le CMS utilisé.
PHP fait tourner une grande partie du web, de WordPress à Drupal en passant par Magento et PrestaShop. Quand une faille touche le langage lui-même, un site parfaitement entretenu reste exposé si la version installée sur son serveur n'est pas corrigée. C'est ce qui explique les nombreux sites passés en maintenance par précaution le 21 octobre, préfectures et sites publics compris.
Cet article fait le point sur la nature des failles, les versions concernées, les gestes à faire tout de suite et les conséquences pour votre référencement naturel.
Que sont les failles PHP2Shell ?
PHP2Shell désigne deux vulnérabilités découvertes dans le moteur PHP, c'est-à-dire dans le langage qui fabrique les pages d'un site dynamique côté serveur. Elles ne visent pas un CMS ou une extension en particulier, mais le socle sur lequel tous ces outils reposent.
Deux failles d'exécution de code à distance sans authentification
Les deux failles mènent au même résultat : une exécution de code à distance (RCE). Un attaquant envoie une requête piégée au serveur, et celui-ci exécute ses instructions sans lui demander de s'identifier. Il peut alors voler des données, modifier des pages ou installer une porte dérobée.
D'après l'avis de sécurité publié par l'équipe PHP, elles touchent la gestion de la mémoire entre deux requêtes :
- CVE-2026-109618 (corruption de la mémoire) : quand la mémoire est saturée, PHP peut être interrompu alors que les données d'une requête ne sont qu'à moitié initialisées, puis les traiter comme valides au moment du nettoyage ;
- CVE-2026-109619 : un état interne lié à une requête peut survivre après la libération de sa mémoire, et être réutilisé par la requête suivante traitée par le même processus.
L'équipe PHP précise que la configuration la plus exposée est Apache avec mod_php : l'attaque peut s'y déclencher avant même l'exécution du code de l'application. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont également concernés.
Des failles trouvées avec l'aide de l'IA
Les chercheurs en sécurité de Calif et de Wiz Research ont identifié ces failles en s'appuyant sur des modèles d'IA de dernière génération, puis les ont signalées à l'équipe PHP dans le cadre d'une divulgation coordonnée. Une fuite publiée le 20 octobre a forcé l'équipe PHP à annoncer en urgence une version corrective, sortie le lendemain. L'épisode montre que l'IA réduit le délai entre la publication d'une faille et son exploitation : un site doit désormais pouvoir se corriger en quelques heures.
Quels sites et quelles versions de PHP sont concernés ?
Toute installation PHP qui répond à des requêtes web est concernée, que le site tourne sous WordPress, Drupal, Joomla, Magento, PrestaShop ou sur un développement sur mesure. Les plateformes hébergées qui ne reposent pas sur PHP (Shopify, Webflow, Wix) ne sont pas concernées pour la partie site, mais un outil annexe en PHP (espace client, back-office, blog séparé) peut l'être.
Les distributions Linux et les éditeurs de support long terme ont reçu les correctifs en avance. Si votre serveur utilise les paquets de sa distribution, vérifiez que sa mise à jour mentionne bien les deux numéros CVE.
{{audit-primary="/cta"}}
Que faire pour protéger votre site ?
La seule protection complète est la mise à jour de PHP. Les autres mesures réduisent l'exposition le temps de la faire, mais ne rendent pas un serveur sûr.
Vérifier sa version de PHP et son hébergeur
Commencez par savoir quelle version de PHP tourne réellement sur votre serveur. Sur WordPress, l'écran « Santé du site » l'affiche dans l'onglet Informations ; sur un hébergement mutualisé, elle figure dans le panneau d'administration de l'hébergeur.
Si votre site est infogéré ou hébergé chez un prestataire, posez-lui deux questions précises :
- quelle version de PHP est installée sur le serveur qui héberge mon site ?
- le correctif des failles CVE-2026-109618 et CVE-2026-109619 est-il appliqué, et depuis quand ?
La plupart des grands hébergeurs appliquent le correctif eux-mêmes, mais pas tous : une réponse floue doit vous pousser à relancer.
Installer le correctif sur le serveur
Si vous administrez votre serveur, installez l'une des quatre versions corrigées, puis redémarrez tous les processus PHP (pools FPM, Apache). Un processus qui n'a pas été relancé continue d'exécuter l'ancien code.
Mettre à jour WordPress, son thème ou ses extensions ne corrige rien ici. La faille est dans le moteur PHP, sous le CMS, et seule une intervention sur le serveur la referme.
Si votre site tourne encore en PHP 8.1 ou avant, c'est le moment de planifier la migration. Ces versions ne reçoivent plus de mises à jour de sécurité régulières, et un correctif ponctuel ne les rend pas sûres pour autant.
Les mesures d'urgence si vous ne pouvez pas mettre à jour
En attendant la mise à jour, l'équipe PHP liste plusieurs réglages qui ferment les chemins d'attaque connus :
- désactiver session.upload_progress.enabled dans le php.ini ou la configuration du pool FPM, puis redémarrer chaque processus ;
- abaisser post_max_size (8M sans envoi de fichiers, 32M sinon) et garder upload_max_filesize en dessous ;
- sur PHP 8.5, désactiver fatal_error_backtraces ;
- limiter la taille et la complexité des requêtes au niveau du serveur web, du proxy ou du pare-feu applicatif (WAF).
Le mode maintenance d'un CMS ne protège pas : PHP analyse la requête avant que l'application ne s'exécute. Si aucune de ces mesures n'est possible rapidement, mettre le site hors ligne le temps de le corriger reste l'option la plus sûre. Toutes les explications techniques figurent dans l'avis de sécurité officiel de PHP.
Failles PHP et SEO : quels risques pour votre référencement ?
Une faille de sécurité devient un sujet SEO de deux façons : quand on coupe le site pour le protéger, et quand il est piraté. La première se gère sans dommage, la seconde peut coûter des mois de visibilité.
Mettre son site en maintenance sans perdre ses positions
Pour une coupure temporaire, le bon signal envoyé à Google est un code erreur 503 (service indisponible), idéalement accompagné d'un en-tête Retry-After. Google comprend que l'indisponibilité est passagère et revient explorer la page plus tard, sans la retirer de l'index.
L'erreur classique consiste à afficher une page « site en maintenance » qui renvoie un code 200 : Google peut alors indexer ce message à la place de vos contenus. Une erreur 500 qui dure signale de son côté un serveur défaillant et ralentit l'exploration. Quelques heures en 503 n'ont pas d'effet durable, plusieurs jours commencent à en avoir.
Repérer un site piraté avant Google
Un serveur compromis sert souvent à des fins SEO : pages de spam injectées, liens cachés, redirections vers des sites douteux selon le visiteur. Ces techniques de black hat SEO exposent votre domaine à une action manuelle et à un avertissement de sécurité affiché dans les résultats de recherche.
Dans les semaines qui suivent, surveillez quelques signaux :
- le rapport « Problèmes de sécurité » de la Google Search Console, qui signale les contenus piratés détectés par Google ;
- une hausse soudaine du nombre de pages indexées, ou des requêtes sans rapport avec votre activité dans le rapport Performances ;
- des requêtes inhabituelles dans les journaux du serveur, que l'analyse de logs permet d'isoler ;
- de nouveaux fichiers PHP ou des comptes administrateurs que personne n'a créés.
En cas de piratage confirmé, nettoyez le serveur, changez tous les accès, puis demandez un réexamen dans la Search Console. Plus la réaction est rapide, plus la perte de trafic reste limitée.
{{rdv-primary="/cta"}}
Comment datashake vous accompagne sur la sécurité technique de votre site
Un site coupé ou piraté ne se positionne plus. L'équipe SEO et GEO de datashake intègre ces vérifications dans son suivi technique, aux côtés de l'exploration, de l'indexation et de la performance.
Concrètement, notre audit technique SEO passe en revue plus de 100 points de contrôle, dont la pile technique du site, les codes de réponse et les signaux d'indexation anormale. En période de crise comme PHP2Shell, nous aidons nos clients à vérifier leur exposition avec leur hébergeur, à poser une maintenance propre en 503 et à surveiller la Search Console ensuite.
FAQ
C'est quoi une faille PHP ?
Une faille PHP est une vulnérabilité dans le langage PHP lui-même ou dans du code écrit en PHP. Avec PHP2Shell, elle se trouve dans le moteur et expose tous les sites qui l'utilisent, quel que soit leur CMS.
Mon site WordPress est-il concerné par les failles PHP2Shell ?
Oui, si le serveur qui l'héberge utilise une version de PHP non corrigée. WordPress, ses thèmes et ses extensions peuvent être à jour, l'exposition dépend uniquement de la version de PHP installée. Vérifiez-la dans l'écran Santé du site ou auprès de votre hébergeur.
Que faire face à une faille PHP critique ?
Il faut installer la version corrigée de PHP sur le serveur dès sa publication, puis redémarrer tous les processus PHP. Si ce n'est pas possible tout de suite, appliquez les mesures d'atténuation publiées par l'équipe PHP ou mettez le site hors ligne avec un code 503. Surveillez ensuite la Search Console et les journaux du serveur.
Une mise en maintenance pénalise-t-elle le référencement ?
Non, si elle est courte et renvoie un code 503. Google comprend qu'il s'agit d'une indisponibilité temporaire et conserve les pages dans son index. Le risque apparaît quand la page de maintenance renvoie un code 200 ou quand la coupure dure plusieurs jours.
