Le 21 octobre 2026, le projet PHP a publié en urgence quatre versions correctives pour deux failles jugées critiques. Ce sont les failles que la presse technique appelle déjà « PHP2Shell ». Dans les heures qui ont suivi, des administrateurs ont préféré couper leurs sites le temps de mettre à jour leurs serveurs. Cette précaution peut coûter cher en référencement si elle est mal faite. John Mueller, de Google, a rappelé dans la foulée quelle réponse le moteur attend d’un site volontairement hors ligne.
Plan de l'article
Deux failles qui touchent presque tous les serveurs PHP #
L’avis de sécurité publié sur php.net annonce les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre à un attaquant non authentifié d’exécuter du code à distance. La veille, le projet avait annoncé une note de gravité de 9,2 sur l’échelle CVSS v4.0 pour les deux failles.
La première exploite la gestion des dépassements de mémoire : PHP peut être interrompu alors que les données internes d’une requête ne sont que partiellement initialisées. La seconde repose sur un état interne qui survit à la libération de sa mémoire, puis peut être réutilisé par une requête suivante traitée par le même processus.
À lire Contenu généré par IA : Google exige désormais une vérification manuelle avant publication
Selon php.net, toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé avec mod_php, pour lequel une attaque a été démontrée avant même l’exécution du code de l’application. Le projet est explicite : la mise à jour est la seule solution complète. Les branches 8.1 et antérieures ne reçoivent plus de correctifs officiels, mais des rétroportages minimaux ont été publiés pour PHP 7.4, 8.0 et 8.1.
Pourquoi cela concerne aussi le SEO
WordPress, PrestaShop, Drupal ou Magento tournent tous sur PHP. Un site compromis, c’est le risque de pages de spam injectées, de redirections malveillantes, et à terme d’un avertissement dans les résultats de recherche. Mais la réaction d’urgence comporte elle aussi un piège. Un site coupé n’importe comment peut sortir de l’index plus vite qu’on ne le pense.
La consigne de Google : un code 503, et rien d’autre #
Comme le rapporte Search Engine Roundtable, John Mueller a publié un message sur Bluesky le 21 octobre. Il y conseille aux sites qui se mettent hors ligne pour ces mises à jour imprévues de renvoyer un code HTTP 503, plutôt que de laisser les requêtes expirer ou de répondre en 404 ou en 500. Il précise que cette réponse peut être servie en dehors de PHP : directement par le serveur web, via un changement de DNS, ou par un CDN.
Le détail compte. Pendant une faille de ce type, le moteur PHP lui-même est en cause. Une page de maintenance générée par une extension WordPress dépend donc encore du composant à protéger. Servir le 503 depuis Nginx, Apache ou le CDN permet de couper PHP tout en envoyant à Googlebot un signal propre.
À lire AI Overviews en France : les premiers chiffres confirment la perte de clics
Ce que dit la documentation officielle
La page de Google consacrée à la mise en pause d’un site va dans le même sens. En cas d’urgence et pour une courte durée, elle recommande de remplacer le contenu par une page d’information renvoyée avec un code 503. Elle prévient que cette option ne doit durer que très peu de temps, « quelques jours au plus ». Pour une fermeture plus longue, Google conseille plutôt de garder une page d’accueil indexable, en code 200, qui explique la situation.
La même page liste les erreurs à éviter :
Les codes 403, 404 et 410. Ils indiquent que la page n’existe plus ou n’est pas accessible, et peuvent faire retirer les URL des résultats.
Le fichier robots.txt. Il doit rester accessible et ne pas interdire tout l’exploration. Google précise qu’un robots.txt servi en 503 bloque toute l’exploration du site.
À lire Spam update de septembre 2026 : Google a terminé le déploiement, ce qu’il faut vérifier
L’outil de suppression temporaire de la Search Console, et le noindex. Ils ne sont pas faits pour une fermeture et retirent les pages de l’index.
Le bon réflexe en pratique #
Pour un éditeur ou une agence qui gère plusieurs sites, l’ordre des opérations est simple. D’abord, vérifier auprès de l’hébergeur ou de la distribution si les paquets corrigés sont disponibles : php.net indique que les distributions Linux et les éditeurs de versions longue durée ont reçu les correctifs à l’avance. Si la mise à jour est immédiate, il n’y a aucune raison de couper le site.
Si elle ne l’est pas et que l’on choisit de fermer, mieux vaut configurer au niveau du serveur web ou du CDN une réponse 503 pour toutes les pages sauf le robots.txt. Un en-tête Retry-After indique en plus au robot quand repasser. Une fois PHP à jour, on retire la règle et on vérifie avec l’outil d’inspection d’URL de la Search Console que les pages répondent de nouveau en 200.
Php.net cite aussi des réglages qui réduisent l’exposition en attendant la mise à jour, comme la désactivation de session.upload_progress.enabled ou une limite basse sur post_max_size. Le projet insiste toutefois : ces mesures ne rendent pas une installation sûre.
À lire Agence Référencement : Top 10 Experts SEO 2026
Une coupure de quelques heures ne coûte presque rien #
Bien gérée, une indisponibilité courte en 503 n’a pas d’effet durable sur le classement : Googlebot comprend que la situation est temporaire et revient plus tard. C’est la coupure prolongée, ou mal signalée, qui fait des dégâts. Un timeout de plusieurs jours, une page blanche en 200 ou une erreur 500 en série envoient de mauvais signaux. Face à une faille de cette gravité, le meilleur service à rendre à son référencement reste de patcher vite et de couper proprement si on ne peut pas faire autrement.
