Alerte PHP : deux failles critiques exposent 70 % d'Internet à un risque majeur, la communauté en émoi

Si vous avez été en ligne aujourd'hui, ne serait-ce qu'un instant, vous avez vu la panique : une vulnérabilité critique menace de « pwn » à peu près tous les sites web de la planète.

La Finlande vient de commencer à débrancher des sites gouvernementaux mercredi, la NSA recommande à toutes les organisations utilisant PHP de fermer leurs sites, et les Pays-Bas et la France ont fait de même. Et non, ce n'était pas une cyberguerre.

Le coupable était PHP, un langage de programmation dont la plupart des gens n'ont jamais entendu parler. Vous l'avez presque certainement utilisé aujourd'hui, cependant : il fait tourner environ 70 % de tous les sites web dont le langage côté serveur est connu, selon W3Techs.

PHP est le logiciel qui travaille dans l'ombre sur le serveur d'un site web—l'ordinateur qui stocke le site et construit chaque page que vous demandez. Chaque site WordPress, par exemple, repose sur un serveur PHP, selon la société de sécurité WordPress Wordfence.

Oh, au fait, Wordfence est aussi hors service.

Deux bogues récemment découverts dans PHP lui-même permettent à un inconnu d'exécuter ses propres commandes sur ce serveur sans jamais se connecter. Les spécialistes de la sécurité appellent cela l'exécution de code à distance non authentifiée. Tous les autres peuvent appeler cela « quelqu'un d'autre conduit maintenant ».

Si ce serveur stocke votre compte, votre adresse ou votre historique de commandes, eh bien, tout cela leur appartient aussi. L'hébergeur web GoDaddy a averti que ces failles pourraient permettre aux attaquants de voler des données, de défigurer des sites ou de prendre entièrement le contrôle des serveurs.

« Une faille comme celle-ci pourrait permettre à un attaquant d'exécuter son propre code sur un serveur affecté via Internet, ce qui peut entraîner le vol de données, la défiguration d'un site ou une prise de contrôle complète », déclare GoDaddy.

Ce que PHP a annoncé

La PHP Foundation, l'organisation à but non lucratif qui finance le développement du langage, a tiré la sonnette d'alarme mardi. Dans une déclaration partagée sur X, elle a déclaré : « L'équipe de sécurité de PHP donne un préavis : une prochaine version de sécurité mercredi 21 octobre 2026, 14h00 UTC, deux vulnérabilités critiques, toutes deux évaluées CVSSv4 9.2. Les utilisateurs de PHP sont encouragés à se préparer à mettre à jour. Version plus tôt si les détails deviennent publics ou en cas de preuve d'exploitation active. »

Ce 9.2 provient du CVSS, le système de notation commun des vulnérabilités, qui évalue la dangerosité d'un bogue en fonction de critères tels que la facilité avec laquelle il peut être atteint via Internet et les dégâts qu'il peut causer. Il va de 0 à 10, et tout ce qui est à partir de 9,0 est qualifié de critique—ces deux-là sont donc à peu près aussi graves que possible sans atteindre un 10 parfait.

Le correctif est arrivé vers 13h35 UTC mercredi, quelques minutes en avance, sous la forme des versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L'avis de sécurité n'a pas pris de gants : « Tous les utilisateurs de PHP sont fortement encouragés à mettre à jour immédiatement. »

Mais publier un correctif et faire en sorte que tout le monde mette en œuvre la solution ne sont pas la même chose, la prudence est donc de mise.

Comment fonctionnent les failles

La première faille, CVE-2026-109618, se manifeste lorsque PHP manque de mémoire au milieu du traitement d'une requête, puis traite ensuite ces données à moitié construites comme si elles étaient terminées. La seconde, CVE-2026-109619, laisse les résidus de la requête d'un visiteur persister en mémoire après qu'ils auraient dû être jetés, où la requête suivante peut trébucher dessus.

Imaginez un cuisinier qui continue de lire des commandes sur des tickets déjà jetés à la poubelle. Glissez un faux ticket dans la corbeille, et le cuisinier prépare tout ce que vous y avez écrit. Dans ce cas, la « commande » est le code de l'attaquant, et le serveur l'exécute.

PHP a déclaré que le risque est le plus élevé sur les serveurs utilisant une configuration Apache courante appelée mod_php, où un exploit démontré fonctionne « avant même que le moindre code applicatif ne s'exécute ». En d'autres termes, les défenses propres au site, comme les écrans de connexion et les plugins de sécurité WordPress, ne se réveillent même pas.

Les chercheurs de la fondation PHP ont pointé du doigt la fonctionnalité de progression d'envoi de PHP, celle qui suit la quantité d'un fichier que vous avez envoyée, comme l'un des vecteurs d'attaque confirmés. Elle est activée par défaut depuis plus d'une décennie, et peu de sites web l'utilisent réellement.

Une fuite, puis des attaques

Rien de tout cela n'était censé être public encore. Mardi, quelqu'un a publié sur le forum Hacker News que deux failles PHP seraient divulguées ce jeudi-là, tout en admettant n'avoir « aucune preuve au-delà de “source : trust me, bro”. »

Il s'avère que le bro avait raison. La société de sécurité watchTowr a confirmé que les failles étaient réelles et sous embargo — un accord visant à garder les détails secrets jusqu'à ce qu'un correctif soit prêt — et PHP a avancé sa publication d'un jour.

« Nous observons l'émergence d'attaques précoces et mettons à jour les mesures d'atténuation à mesure que de nouveaux vecteurs apparaissent », a écrit sur X Dane Knecht, directeur technique de Cloudflare, tôt mercredi matin, près de six heures avant la publication du correctif. Cloudflare a déployé des règles de pare-feu d'urgence, des filtres qui bloquent les schémas d'attaque connus, pour tous ses clients, mais Knecht les a qualifiées de « simple mesure provisoire ».

Les gouvernements actionnent l'interrupteur

Le centre informatique de l'État finlandais, Valtori, a commencé à mettre hors ligne des services web publics par précaution, a rapporté le diffuseur public Yle, tandis que l'agence nationale de cybersécurité néerlandaise a mis hors ligne son propre site web.

Le ministère de l'Intérieur français a déclaré que les sites web de ses préfectures avaient été « temporairement mis hors ligne dans l'attente de la publication d'un correctif de sécurité par l'éditeur du framework ».

CERT-EU, l'équipe européenne d'urgence cybernétique, a conseillé aux organisations qui ne pouvaient pas appliquer le correctif de « envisager d'isoler les applications exposées à Internet des réseaux publics jusqu'à ce qu'un correctif soit disponible ». C'est du langage bureaucratique pour dire « débranchez-le ». Les agences en Australie, au Japon et au Royaume-Uni ont dit à peu près la même chose, selon Reuters.

Ce que les publications virales ont eu tort de dire

Des fils viraux sur X affirmaient que des versions de PHP « remontant à 2004 » étaient vulnérables. Cela remonte aux premières estimations selon lesquelles tout ce qui est sorti depuis PHP 5 était affecté, ce que CERT-EU a admis être fondé sur des publications sur les réseaux sociaux.

L'entreprise de sécurité e-commerce Sansec situe la plage à PHP 5.4 et versions ultérieures. Donc 2012, pas 2004 — ce qui reste bien ancien.

PHP ne publie des versions officielles que pour les versions 8.2 et ultérieures, ce qui rend l'affirmation « pas de correctif pour les anciennes versions » à moitié vraie. Vu la gravité de celle-ci, son équipe de sécurité a également publié des correctifs de code source minimalistes pour 7.4, 8.0 et 8.1, et les distributions Linux rétroportent leurs propres correctifs.

L'entreprise de sécurité Mallory a compté environ 884 000 hôtes exposés à Internet annonçant PHP 8.1 ou une version antérieure le 20 octobre, soit 59 % des quelque 1,5 million qui affichent publiquement une version. Un seul serveur d'hébergement mutualisé peut héberger de nombreux sites web, donc le nombre de sites derrière eux est plus élevé.

Certains fils ont aussi inclus Node.js, une technologie web différente qui avait justement programmé sa propre mise à jour de sécurité, sans rapport, pour le même jour. Mauvais timing.

Même les versions corrigées n'atteindront pas tous les serveurs en même temps. « Si vous dépendez du dépôt maintenu par des bénévoles https://rpms.remirepo.net, nous vous exhortons à passer dès maintenant aux paquets de votre distribution ou à compiler depuis les sources, afin de pouvoir appliquer immédiatement les mises à jour. Le dépôt n'aura pas de mises à jour aujourd'hui », a déclaré la PHP Foundation dans son communiqué, en référence à une source populaire de paquets PHP gérée par des bénévoles pour les serveurs Linux de type Red Hat.

Faut-il vraiment s'en soucier ?

Vous ne devriez pas paniquer, mais vous ne devriez pas non plus hausser les épaules. Un site web piraté, par exemple, n'a pas besoin de toucher à une blockchain pour vider votre portefeuille. En 2024, des attaquants ont redirigé les interfaces des protocoles DeFi Compound et Celer vers des pages qui vidaient les portefeuilles connectés, et Curve Finance a subi une attaque similaire en 2025.

Il s'agissait de détournements DNS, et non de failles PHP, mais le procédé est le même : le site semble correct, l'URL semble correcte, et le bouton « approuver » envoie vos jetons ailleurs. Un serveur compromis peut servir exactement ce genre de page.

Les pirates peuvent faire preuve de beaucoup de créativité, très rapidement, lorsqu'il s'agit d'exploits zero-day.

Ces failles sont aussi de plus en plus faciles à trouver, les modèles d'IA de pointe étant de plus en plus utilisés pour découvrir des vulnérabilités logicielles, et des experts ont déclaré à Decrypt en juin que bien d'autres vulnérabilités pourraient apparaître à mesure que ces outils se répandent.

Que se passe-t-il ensuite, et que faire

Une fois un correctif public, les attaquants peuvent comparer l'ancien et le nouveau code pour voir exactement ce qui a été corrigé, et l'équipe forensique de la société de cybersécurité Sansec a déclaré qu'elle s'attend à ce que « des attaques massives commencent dans les 15 minutes suivant la publication ». Lorsqu'une autre faille PHP est devenue publique en juin 2024, Akamai a constaté des tentatives d'exploitation contre ses serveurs leurres en moins de 24 heures.

Alors, la personne moyenne doit-elle paniquer ? Pas exactement. Votre téléphone, votre navigateur et votre ordinateur portable n'ont pas besoin d'un correctif PHP ; le travail incombe à ceux qui gèrent les sites web que vous utilisez.

Si vous gérez un site, demandez à votre hébergeur si PHP a été mis à jour, et ne comptez pas sur WordPress pour le faire à votre place : Wordfence a averti que les mises à jour automatiques n'appliqueront pas ce correctif et a demandé aux propriétaires de sites de déterminer qui est responsable de la mise à jour de PHP sur leurs serveurs. Toute personne utilisant la version 8.1 ou une version antérieure doit planifier une mise à niveau.

« La seule chose que je peux dire, c'est que la seule atténuation consiste à corriger / mettre à niveau PHP », a déclaré la développeuse du cœur de PHP Gina Peter Banyard sur Mastodon. « Je sais malheureusement trop de choses. »

Et si vous êtes sur PHP 8.2, le correctif que vous venez de recevoir est l'un de vos derniers : cette version atteint sa fin de vie le 31 décembre 2026, après quoi elle ne recevra plus de correctifs de sécurité.