PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre pour corriger CVE-2026-109618 et CVE-2026-109619, deux vulnérabilités notées 9,2 sur 10 qui permettent l'exécution de code à distance sans authentification.

Ces vulnérabilités ont poussé la Finlande, les Pays-Bas et la France à mettre des sites gouvernementaux hors ligne par précaution après la divulgation anticipée de détails techniques. Cloudflare a également signalé des attaques plusieurs heures avant la publication du correctif. La National Security Agency américaine a recommandé aux organisations utilisant PHP de fermer leurs sites, tandis que des agences en Australie, au Japon et au Royaume-Uni ont émis des consignes similaires.

La plupart des internautes n'ont rien à installer. La responsabilité d'appliquer le correctif incombe aux exploitants de sites web, aux sociétés d'hébergement et aux organisations qui maintiennent des serveurs PHP. PHP 8.1 et les versions antérieures ne reçoivent pas de versions officielles régulières, bien que l'équipe de sécurité de PHP ait publié des correctifs limités au code source pour certaines anciennes versions en raison de la gravité du problème.

PHP fait tourner environ 70 % des sites dont le langage côté serveur est connu, selon W3Techs. Ce langage de programmation fonctionne sur les serveurs, où il sert à stocker les sites web et à générer les pages demandées par les visiteurs. Les sites WordPress reposent par exemple couramment sur des serveurs PHP, selon la société de sécurité WordPress Wordfence.

Les deux failles peuvent permettre à un attaquant d'exécuter des commandes sur un serveur PHP sans se connecter. Ce type de vulnérabilité est appelé exécution de code à distance sans authentification. Selon le serveur et les données qu'il stocke, une attaque réussie pourrait exposer des informations de compte, des adresses, des historiques de commandes ou d'autres données sensibles.

L'hébergeur web GoDaddy a averti que ces vulnérabilités pourraient permettre à des attaquants de voler des données, de défigurer des sites web ou de prendre le contrôle complet des serveurs concernés.

« Une faille de ce type pourrait permettre à un attaquant d'exécuter son propre code sur un serveur affecté via Internet, ce qui peut conduire au vol de données, à la défiguration d'un site ou à une prise de contrôle totale », a déclaré GoDaddy dans sa mise à jour de sécurité.

L'annonce de sécurité de PHP

La PHP Foundation, l'organisation à but non lucratif qui finance le développement du langage, a lancé une alerte anticipée le 20 octobre. Dans une déclaration partagée sur X, elle a indiqué :

« L'équipe de sécurité de PHP donne un préavis : prochaine version de sécurité 21 octobre 2026, 14h00 UTC, deux vulnérabilités critiques, toutes deux notées CVSSv4 9,2. Les utilisateurs de PHP sont invités à se préparer à mettre à jour. Publication anticipée si les détails deviennent publics ou en cas de preuve d'exploitation active. »

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

Le Common Vulnerability Scoring System, ou CVSS, note les vulnérabilités de 0 à 10 selon des facteurs tels que la facilité d'exploitation via Internet et l'impact potentiel. Les scores de 9,0 ou plus sont classés comme critiques.

PHP a publié le correctif vers 13h35 UTC le 21 octobre, soit environ 25 minutes avant l'heure annoncée. L'avis de sécurité indiquait : « Tous les utilisateurs de PHP sont fortement encouragés à mettre à jour immédiatement. » La publication a été avancée d'un jour après la circulation publique d'informations sur les vulnérabilités et l'apparition de preuves d'attaques.

Comment fonctionnent les vulnérabilités

CVE-2026-109618 se manifeste lorsque PHP manque de mémoire pendant le traitement d'une requête et traite ensuite des données partiellement construites comme si elles étaient complètes. CVE-2026-109619 permet à des restes de la requête d'un visiteur de persister en mémoire après avoir dû être supprimés, permettant à une requête ultérieure d'interagir avec ces restes.

Le risque est le plus élevé sur les serveurs utilisant mod_php, une configuration Apache courante. PHP a indiqué qu'un exploit démontré fonctionne « avant l'exécution de tout code applicatif », ce qui signifie que les défenses mises en place par le site lui-même — comme les écrans de connexion et les plugins de sécurité WordPress — peuvent ne pas avoir l'occasion d'intervenir.

Les chercheurs de la PHP Foundation ont identifié la fonctionnalité d'upload-progress de PHP comme l'une des voies d'accès confirmées à la vulnérabilité. Cette fonctionnalité, qui suit la progression d'un téléversement de fichier, est activée par défaut depuis plus de dix ans et est peu utilisée par les sites web.

De plus amples informations techniques sont disponibles dans les archives de sécurité PHP, l'analyse de watchTowr et la fiche NVD de CVE-2026-109619. La documentation de PHP décrit également la configuration de session concernée.

Des détails divulgués avant le correctif

La divulgation ne devait initialement pas avoir lieu avant la publication prévue. Mardi, un utilisateur a publié sur le forum Hacker News que deux vulnérabilités PHP seraient divulguées le jeudi, tout en admettant que l'affirmation n'avait « aucune preuve au-delà de 'source : fais-moi confiance' ». La publication est disponible ici.

La société de sécurité watchTowr a ensuite confirmé que les vulnérabilités étaient réelles et couvertes par un embargo, un accord visant à garder les détails techniques confidentiels jusqu'à ce qu'un correctif soit prêt. PHP a alors accéléré la publication.

Le CTO de Cloudflare, Dane Knecht, a déclaré sur X tôt mercredi que des attaques avaient déjà commencé, près de six heures avant la publication du correctif. Cloudflare a déployé des règles d'urgence de pare-feu applicatif web auprès de ses clients, y compris ceux des offres gratuites, mais Knecht a décrit ces règles comme une simple mesure temporaire.

« PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026 »

La publication originale est également disponible sur le compte X de Dane Knecht.

Les gouvernements mettent des sites hors ligne

Le centre informatique de l'État finlandais, Valtori, a commencé à mettre les services web publics hors ligne par précaution, selon la radiodiffuseur public Yle. L'agence nationale de cybersécurité néerlandaise a également fermé son propre site web.

Le ministère français de l'Intérieur a indiqué que les sites des 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 ».

L'équipe d'urgence cyber de l'Union européenne, CERT-EU, a demandé aux organisations ne pouvant pas appliquer le correctif d'« envisager d'isoler les applications exposées à Internet des réseaux publics jusqu'à ce qu'un correctif soit disponible ».

Reuters a rapporté que des agences en Australie, au Japon et au Royaume-Uni ont émis des consignes similaires. Le rapport de Reuters indiquait également que des sites web pourraient devoir être mis hors ligne pendant que les opérateurs se préparaient à installer les correctifs.

Les affirmations sur les versions PHP concernées

Des publications circulant sur X prétendaient que des versions de PHP « remontant à 2004 » étaient vulnérables. Cette affirmation provenait d'estimations initiales selon lesquelles toutes les versions depuis PHP 5 étaient concernées, une évaluation que CERT-EU a reconnu être fondée sur des publications sur les réseaux sociaux.

La société de sécurité e-commerce Sansec a estimé que PHP 5.4 et les versions ultérieures étaient concernées, ce qui ramènerait la fourchette à 2012 plutôt qu'à 2004. PHP ne fournit officiellement des versions actuelles que pour les versions 8.2 et ultérieures. Toutefois, en raison de la gravité de ces vulnérabilités, l'équipe de sécurité a également publié des correctifs de base au code source pour PHP 7.4, 8.0 et 8.1, tandis que les distributions Linux ont commencé à rétroporter les correctifs de leur côté.

La société de sécurité Mallory a comptabilisé environ 884 000 hôtes exposés à Internet affichant PHP 8.1 ou antérieur au 20 octobre. Cela représentait 59 % des quelque 1,5 million d'hôtes visibles publiquement qui identifiaient leur version PHP. Le nombre de sites web concernés est plus élevé car un seul serveur d'hébergement mutualisé peut soutenir de nombreux sites. Les recherches de Mallory sont disponibles ici, et l'analyse de Sansec est disponible ici.

Certaines publications en ligne ont également mêlé Node.js à la discussion. Node.js est une technologie web distincte qui avait simplement programmé sa propre mise à jour de sécurité, sans rapport, le même jour.

La PHP Foundation a averti que les versions corrigées ne seraient pas disponibles partout en même temps. Elle a déclaré : « If you rely on the volunteer maintained we urge you to move to distro packages or building from source now, so you can immediately apply updates. The repo will not have updates today », en référence à une source de paquets PHP maintenue par des bénévoles pour les serveurs Linux de type Red Hat. Le dépôt de paquets est disponible à l'adresse

Impact potentiel sur les sites web et les actifs numques

Un site web compromis n'a pas besoin d'interagir directement avec une blockchain pour mettre en péril les actifs numériques des utilisateurs. En 2024, des attaquants ont redirigé les interfaces frontales des protocoles DeFi Compound et Celer vers des pages conçues pour vider les portefeuilles connectés. Curve Finance a subi une attaque similaire en 2025. Ces incidents impliquaient des détournements DNS plutôt que des vulnérabilités PHP, mais le résultat peut sembler similaire pour un visiteur : le site et l'URL paraissent légitimes alors qu'une action d'approbation envoie les tokens ailleurs.

Un serveur PHP compromis pourrait être utilisé pour servir une page frauduleuse de ce type. La relation entre une infrastructure web vulnérable et le vol de cryptomonnaies a également été évoquée par l'entrepreneur @levelsio, qui a déclaré sur X avoir déconnecté ses sites et serveurs privés virtuels en attendant le correctif.

« I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026 »

La publication est également disponible sur X. Les précédents reportages de Decrypt sur l'incident Compound et Celer et l'attaque contre Curve sont disponibles ici et ici.

Ces vulnérabilités surviennent alors que les modèles d'intelligence artificielle de pointe sont de plus en plus utilisés pour identifier des failles logicielles. Des experts ont déclaré à Decrypt en juin que la diffusion de ces outils pourrait conduire à la découverte de nombreuses autres vulnérabilités. Le reportage de Decrypt est disponible ici.

Ce que les exploitants de sites doivent faire

Une fois qu'un correctif devient public, les attaquants peuvent comparer le code vulnérable et le code corrigé pour déterminer ce qui a changé. L'équipe d'investigation de la société de cybersécurité Sansec a indiqué s'attendre à « ce que des attaques de masse commencent dans les 15 minutes suivant la publication ». Lorsqu'une autre vulnérabilité PHP avait été divulguée en juin 2024, Akamai avait enregistré des tentatives d'exploitation contre ses serveurs leurre dans les 24 heures. L'analyse d'Akamai est disponible ici.

Les téléphones, navigateurs et ordinateurs portables personnels n'ont pas besoin d'une mise à jour PHP. Le travail incombe aux organisations qui exploitent des sites web et des serveurs. Les propriétaires de sites doivent demander à leurs hébergeurs si PHP a été mis à jour et identifier qui est responsable de la maintenance du serveur.

Wordfence a averti que les mises à jour automatiques de WordPress n'appliqueraient pas ce correctif. Les propriétaires de sites doivent donc vérifier que PHP lui-même a été corrigé plutôt que de supposer qu'une mise à jour de WordPress réglera le problème.

Le développeur principal de PHP, Gina Peter Banyard, a déclaré sur Mastodon : « The only thing I can say is that the only mitigation is patching / upgrading PHP », ajoutant : « I sadly know too much. » La publication est disponible ici.

Les organisations utilisant PHP 8.1 ou antérieur doivent planifier une mise à niveau, car ces versions ne reçoivent pas de versions officielles régulières. Les utilisateurs de PHP 8.2 font également face à une échéance prochaine : PHP 8.2 atteint sa fin de vie le 31 décembre 2026, après quoi il ne recevra plus de correctifs de sécurité.