PHP2Shell : deux failles critiques menacent les sites WordPress et leur SEO

PHP2Shell est le surnom donné à deux failles du moteur PHP, enregistrées sous les références CVE-2026-109618 et CVE-2026-109619. Ce moteur fait tourner WordPress et ses extensions. Chaque faille est notée 9,2 sur 10 sur l’échelle de gravité CVSS 4.0. Depuis le 21 octobre, le CERT-FR conseille d’isoler les serveurs qui ne peuvent pas être corrigés.

Un même site dépend parfois de plusieurs prestataires. Face à la faille PHP2Shell, l’hébergeur, le mainteneur WordPress et l’agence SEO peuvent chacun penser que la mise à jour revient à un autre. L’entreprise doit savoir qui installe le correctif et qui contrôle le site à son retour en ligne. Une coupure mal préparée bloque aussi les demandes de devis et les paiements tant que le site reste hors ligne.

Ce que PHP a corrigé le 21 octobre 2026

Les quatre versions corrigées sont sorties le 21 octobre à 16 h, heure de Paris, avec deux avis techniques sur GitHub. Le premier décrit une corruption de la mémoire quand PHP en manque au milieu d’une requête. Le second porte sur un état interne que la requête suivante peut réutiliser après la libération de sa mémoire.

Les deux failles permettent d’exécuter du code sans authentification, avec les droits du compte qui fait tourner le serveur Web. L’avis consacré à CVE-2026-109619 signale aussi une divulgation de mémoire. PHP considère comme exposées toutes les installations qui répondent à des requêtes Web (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed). Le risque est jugé le plus élevé avec mod_php, le module PHP du serveur Apache.

Versions corrigées et fin du support de sécurité

Sources : annonce de sécurité de PHP du 21 octobre 2026 et page des versions prises en charge sur php.net, consultées le 23 octobre 2026.

Pour PHP, aucun réglage ne remplace la mise à jour : les mesures provisoires réduisent certaines voies d’attaque sans rendre l’installation sûre. Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs à l’avance.

Faille PHP2Shell : ce que l’on sait de l’exploitation

Le CERT-FR a mis à jour son alerte CERTFR-2026-ALE-014 le 22 octobre. Il a connaissance de preuves de concept pour certains déploiements, sans faire état d’une exploitation active confirmée. La société watchTowr dit avoir observé, dès le 21 octobre, des attaques sur son réseau de serveurs leurres, sans en publier le volume.

Pour Cybermalveillance.gouv.fr, le risque est surtout critique pour les sites transactionnels et pour ceux qui traitent des données sensibles. Au 23 octobre, aucun organisme n’a publié de nombre de sites compromis ni de mesure des pertes de trafic liées à ces failles.

Rien ne permet donc d’affirmer que les sites WordPress ont été piratés en masse. Un site reste en revanche exposé tant que sa version de PHP n’est pas corrigée, quelle que soit celle de WordPress.

Qui applique le correctif selon votre hébergement

La personne qui installe la version corrigée dépend du mode d’hébergement. Un contrat de maintenance WordPress couvre en général le cœur du CMS et les extensions. Il ne donne pas toujours accès au serveur.

Qui installe la version corrigée, selon l’hébergement

Répartition la plus courante, à confirmer dans chaque contrat.

Sur un hébergement mutualisé, le client choisit souvent lui-même la branche de PHP dans son espace d’administration. Un site resté en 8.1 pour garder une ancienne extension ne recevra aucune version corrigée de PHP. Il faut alors migrer, après tests, de préférence vers 8.3 ou plus, car 8.2 perd son support le 31 décembre 2026.

Mise à jour PHP : servir un code 503 pendant la coupure

Le 21 octobre, Google Search Central a publié sur LinkedIn un rappel destiné aux équipes qui coupent leurs serveurs pour appliquer ces correctifs. Un code HTTP 503 signale une indisponibilité temporaire et conserve dans les résultats les URL déjà indexées pendant l’intervention.

John Mueller, de Google, a précisé sur Bluesky que ce code peut venir d’un CDN ou d’un DNS pointé ailleurs. Quand PHP est arrêté, il ne peut plus envoyer ce code lui-même. La page de maintenance se prépare donc en amont, avec le gestionnaire du serveur ou du CDN.

Une erreur 404 indique à Google que la page n’existe plus. Google retire alors l’URL de son index. La documentation de Google fixe aussi des limites au 503 :

• Durée courte : quelques heures, 1 ou 2 jours au plus.
• Fichier robots.txt : il continue de répondre normalement, car un 503 sur ce fichier bloque toute l’exploration.
• Plusieurs jours de 503 : une URL qui renvoie ce code plusieurs jours de suite peut sortir de l’index.
• Métadonnées figées : pendant la coupure, Google n’actualise ni les titres ni les données structurées.

Quand les erreurs serveur se multiplient, Google ralentit l’exploration de tout le nom d’hôte, puis l’accélère de nouveau quand le site répond en 200.

Après le correctif : les contrôles qui clôturent l’intervention

Un site qui s’affiche de nouveau n’utilise pas forcément la version corrigée, car les processus PHP-FPM ou le serveur Web doivent d’abord être redémarrés. La vérification porte ensuite sur 6 points, consignés par écrit.

1. Version de PHP : celle qu’affiche WordPress sous Outils, Santé du site, onglet Informations.
2. Codes HTTP : une réponse 200 pour l’accueil, les pages de service et le fichier robots.txt.
3. Parcours de conversion : un envoi réel du formulaire de devis et un paiement test.
4. Intégrité des contenus : pas de page ajoutée, de redirection inconnue ni de compte administrateur créé pendant l’exposition.
5. Search Console : le rapport Problèmes de sécurité et l’état de l’hôte dans les statistiques d’exploration.
6. Compte rendu daté : heures de coupure, version installée et contrôles faits, avec le nom de leur auteur.

Le contrôle des contenus devient prioritaire si le correctif arrive plusieurs jours après le 21 octobre. Toute modification suspecte ouvre alors une procédure d’incident, distincte de la simple mise à jour.

Écrire une procédure commune aux trois prestataires

Le prestataire technique applique le correctif et vérifie que le site fonctionne. L’agence SEO contrôle ensuite l’exploration et l’indexation. Suivre la visibilité organique ne la rend pas responsable du serveur, dont elle n’a d’ailleurs pas toujours les accès. Les droits ouverts à chacun, y compris à un agent IA connecté par le MCP WordPress, se fixent dans la même procédure.

Un forfait de maintenance prévoit souvent des mises à jour mensuelles, alors que PHP demande ici une mise à jour immédiate. Le délai d’intervention en cas de faille critique s’écrit donc dans un accord de niveau de service.

Dans une externalisation répartie entre plusieurs prestataires, chaque étape reçoit un intervenant nommé et une preuve attendue.

Les étapes à attribuer avant le prochain correctif urgent

Rediriger le DNS vers une page de maintenance suppose de connaître le titulaire du nom de domaine et de l’hébergement. Les comptes des prestataires se vérifient aussi avant l’incident, à partir des droits d’accès accordés à chaque niveau de support.

Ce qu’il faut demander par écrit cette semaine

Demandez à chaque prestataire la version de PHP en service, sa date d’installation et le nom de la personne qui a vérifié le site. Une réponse écrite de chacun montre l’étape qui n’a pas de responsable.

Les engagements à reporter ensuite dans les contrats figurent dans notre guide des clauses d’un contrat d’externalisation.

Sources et références

Cet article s’appuie notamment sur l’annonce de sécurité de PHP du 21 octobre 2026, les avis techniques de PHP sur la corruption de mémoire (CVE-2026-109618) et sur l’état interne réutilisé (CVE-2026-109619), la page des versions prises en charge par PHP, l’alerte CERTFR-2026-ALE-014 du CERT-FR et l’alerte de Cybermalveillance.gouv.fr sur les failles de PHP. Il repose aussi sur la FAQ de watchTowr consacrée à PHP2Shell, sur la documentation de Google relative aux codes d’état HTTP, à la réduction de la fréquence d’exploration et à la mise en pause d’un site, et sur l’article de Search Engine Journal du 21 octobre 2026.