Failles PHP d’octobre 2026, ce que ça change vraiment pour votre site

Il y a plusieurs jours, mercredi 21 octobre, plusieurs sites publics se sont retrouvés en maintenance du jour au lendemain. J’avoue que mon premier réflexe a été de me demander si on assistait à une cyberattaque géante.

Après avoir lu pas mal d’articles, la réalité est plus nuancée, et surtout plus instructive pour nous qui avons un site ou un blog.

Qu’est-ce que PHP, déjà ?

PHP est un langage qui tourne sur le serveur qui héberge votre site. On ne le voit jamais, mais c’est lui qui fabrique les pages quand un visiteur arrive. WordPress, que j’utilise ici pour UnSimpleClic, repose dessus.

Autrement dit, quand PHP a un problème, ce n’est pas un détail réservé aux informaticiens. C’est tout simplement le sol sous les pieds d’une énorme partie du web qui s’écroule.

Ce qui s’est passé

Le 20 octobre au soir, l’équipe de sécurité de PHP a prévenu qu’une mise à jour importante arrivait le lendemain. Deux failles critiques, toutes deux notées 9,2 sur 10 en gravité.

Ces failles sont référencées sous les numéros CVE-2026-109618 et CVE-2026-109619. Certains spécialistes les ont surnommées PHP2Shell.

Le plus inquiétant tient à ce qu’elles permettraient. En effet, un pirate pourrait exécuter du code à distance sur un serveur vulnérable, et sans avoir besoin d’un identifiant. En clair, il pourrait donner des ordres à la machine sans y être invité.

Une fuite a bousculé le calendrier

Ce qui m’a un peu surpris, c’est que la date de publication a été avancée. D’après plusieurs sources, un message publié sur un forum, depuis supprimé, évoquait ces failles avec un outil dédié. La divulgation était prévue le 22, elle a finalement eu lieu le 21.

Les correctifs sont sortis le 21 octobre en fin d’après-midi, heure de Paris. Ils concernent les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 de PHP.

Pourquoi des sites ont été coupés

Le ministère français de l’Intérieur a indiqué avoir mis ses sites concernés en maintenance préventive, à la demande de l’ANSSI. La NSA américaine a de son côté recommandé une mise à jour immédiate.

Un point m’a semblé important. Un site en maintenance n’a pas forcément été piraté. Ces administrations ont préféré tout fermer le temps de corriger, plutôt que de laisser une porte ouverte. C’est un choix de prudence, pas la preuve d’une catastrophe.

Une semaine plus tard, où en est-on ?

Le 21 octobre, on parlait surtout de risque. Une semaine après, il faut reconnaître que des attaques ont bel et bien eu lieu.

Le plus marquant à mes yeux, c’est que les pirates avaient de l’avance. Le 17 octobre, soit quatre jours avant la publication des correctifs, un honeypot d’Amazon a reçu une tentative d’exploitation. Un honeypot, c’est un faux serveur installé exprès pour attirer les attaquants et observer ce qu’ils font.

D’autres signaux sont allés dans le même sens. La société de sécurité Patchstack a reçu, dès le matin du 21 octobre, des remontées d’hébergeurs signalant des tentatives d’exploitation, avant même la sortie du correctif. Cloudflare disait aussi observer du trafic d’attaque visant ses clients, et des outils d’attaque circulent désormais publiquement.

Il faut pourtant rester prudent, car les avis ne sont pas unanimes. Amazon a estimé le lendemain que les failles étaient exploitées à grande échelle, alors que la société Sansec jugeait au même moment une exploitation massive moins probable qu’elle ne l’avait craint le jour de la sortie. Et d’après Recorded Future, les informations disponibles ne permettent pas de mesurer combien de sites ont réellement été compromis.

Ce que je retiens, c’est qu’il y a eu des tentatives, que l’ampleur des dégâts reste floue, et qu’il n’y a donc aucune raison de se rassurer à bon compte.

Ce que ces failles révèlent vraiment

C’est la partie qui m’intéresse le plus, parce qu’elle dépasse l’actualité du moment.

Le problème n’est pas dans votre site. Il se situe dans PHP lui-même. Vous pouvez avoir le thème le plus propre du monde et des extensions irréprochables, cela ne change rien.

Le délai pour réagir est devenu très court. Entre la découverte d’une faille et les premières attaques, il ne se passe plus des semaines. Ici, des tentatives ont même précédé le correctif. C’est, selon moi, la vraie leçon de cette histoire.

Les failles peuvent dormir très longtemps. D’après la société de sécurité Wiz, relayée par Clubic, des versions de PHP remontant à la 5.4 sont concernées par au moins l’une des deux failles. Une des causes aurait même été identifiée dès 2024 sans être corrigée. Ce n’est pas un scandale à mes yeux, c’est surtout un rappel que le code vieillit et que personne n’est à l’abri.

Mettre à jour WordPress ne suffit pas. C’est le point que je retiens le plus. PHP se met à jour au niveau du serveur, donc chez votre hébergeur ou chez vous si vous gérez votre propre machine. Vous pouvez avoir un WordPress parfaitement à jour sur un PHP dépassé.

Les vieilles versions sont les plus exposées. Les versions 8.1 et antérieures ne reçoivent aucun correctif officiel. Pour la branche 8.2, la fin de vie est annoncée pour le 31 décembre 2026. Le CERT-FR recommande, pour les versions sans correctif, d’isoler puis de migrer.

Ce que j’ai fait de mon côté

Jeudi soir, à 22 h, je n’avais pas le temps de m’en occuper correctement. J’ai donc préféré mettre UnSimpleClic.com en maintenance, par précaution.

Vendredi midi, j’ai mis à jour PHP, puis j’ai testé le site pour m’assurer que tout fonctionnait. Rien à signaler, le site est revenu à la normale.

Je ne dis pas que c’est la seule bonne méthode, mais fermer quelques heures m’a semblé plus raisonnable que de laisser un site ouvert en espérant que tout se passe bien. Et ce test final, même rapide, je ne le sauterais pas.

Ce que je ferais à votre place

Si vous n’avez encore rien vérifié, il n’est pas trop tard. Pas besoin d’être technicien pour agir, voici l’ordre dans lequel je m’y prendrais.

1. Regarder quelle version de PHP tourne chez vous. L’espace client de votre hébergeur l’indique généralement, souvent dans les réglages du site.
2. Écrire à l’hébergeur si le doute persiste. Une simple question suffit. A-t-il appliqué les correctifs de sécurité publiés le 21 octobre ?
3. Passer à une version supportée si vous êtes sur une ancienne. Faites une sauvegarde complète avant, au cas où une extension réagirait mal.
4. Tester son site après la mise à jour. Ouvrez la page d’accueil, un article, et connectez-vous à l’administration pour vérifier que tout répond normalement.
5. Regarder si quelque chose cloche. Puisque des tentatives ont eu lieu avant le correctif, jetez un œil à la liste de vos comptes administrateurs et à vos pages. Un compte ou une page que vous ne connaissez pas mérite une vraie question à votre hébergeur.

La mise à jour ferme la porte, mais elle ne dit pas si quelqu’un est déjà entré avant. C’est mon raisonnement personnel, pas une consigne officielle, mais il me paraît de bon sens.

Pour ceux qui n’ont pas pu mettre à jour tout de suite, un spécialiste du SANS Institute indiquait que désactiver l’option session.upload_progress.enabled apportait une protection partielle. Mais ce n’est qu’un pansement, pas une solution. La vraie réponse reste la mise à jour.

Le même spécialiste faisait aussi remarquer que la plupart des sites n’utilisent pas PHP téléchargé directement depuis php.net. Il faut donc surtout attendre que l’hébergeur ou la distribution serveur publie son propre paquet corrigé. D’ailleurs, certains, comme Ubuntu, l’ont fait dès le premier jour.

Ce que j’en retiens

Cette histoire m’a rappelé quelque chose de simple. On passe du temps à choisir un thème, à soigner ses articles, et on oublie ce qui tient tout cela debout.

Je ne vous demande pas de devenir expert en serveurs. Je vous propose juste de poser une question à votre hébergeur, une fois, et de noter la réponse. C’est un petit geste qui vaut largement ces dix minutes.

Et vous, savez-vous quelle version de PHP fait tourner votre site ?

 

Image – source 1, source 2