Seize heures, heure de Paris. À cet instant, l’équipe de sécurité de PHP publiera le correctif de deux failles critiques de PHP. Elles se logent au cœur du langage qui fait tourner WordPress, WooCommerce, Magento et bien des back-offices du web. Dès lors, les attaquants compareront l’ancien code et le nouveau pour reconstituer l’exploit. La société néerlandaise Sansec attend donc les premières attaques de masse un quart d’heure plus tard. Les administrateurs français n’avaient pas besoin de ça, quatre jours après la vague de cyberattaques du 17 octobre.
- Les failles critiques CVE-2026-109618 et 109619 ont été découvertes dans PHP, menaçant la sécurité de nombreuses plateformes web.
- Un correctif a été publié le 21 octobre à 16h, mais seuls les serveurs sous PHP 8.2 et plus récents bénéficieront d’un patch officiel.
Failles critiques PHP : ce que l’on sait de CVE-2026-109618 et CVE-2026-109619
Tout commence lundi 20 octobre au matin, par un message sur Hacker News annonçant deux vulnérabilités critiques de PHP. Le billet disparaît, pas les captures d’écran. L’une d’elles montre un outil d’attaque baptisé PHP2Shell, attribué à un certain Calif.IO. Sa bannière revendique de fonctionner sur toutes les versions depuis PHP 5.4.0, sortie en 2012. Dans l’après-midi, les chercheurs de watchTowr confirment que les failles sont réelles et qu’ils ont reproduit la première. Pourtant, tout le monde devait attendre jeudi.
L’embargo, cet accord par lequel chercheurs et éditeur gardent le silence jusqu’au correctif, a donc volé en éclats. Le soir même, l’équipe de sécurité de PHP a avancé sa publication au mercredi 21 octobre à 14h00 UTC. Ces deux failles critiques de PHP sont notées 9,2 sur 10 sur l’échelle de gravité CVSS v4.0. Les deux bugs portent les numéros CVE-2026-109618 et CVE-2026-109619. Il s’agit d’exécutions de code à distance, ou RCE. Autrement dit, une requête web bien formée suffit à faire exécuter n’importe quelle commande par le serveur.
Le reste est encore sous scellés. PHP publiera les versions touchées par ces failles critiques, et les versions corrigées, avec le correctif. L’équipe se réserve aussi le droit de sortir plus tôt « si des détails devenaient publics ou si une exploitation active apparaissait ». Huntress n’avait observé aucune attaque chez ses clients au 20 octobre. De plus, aucun code d’exploitation public n’a été identifié, malgré une courte vidéo de démonstration mise en ligne puis retirée.
Pourquoi ces failles critiques PHP touchent vos bitcoins
Vous ne codez pas en PHP ? Votre argent, si. La boutique qui accepte vos paiements en USDC tourne presque toujours sur WooCommerce, Magento ou Shopware. De même, le site vitrine de votre exchange, son blog et son support client reposent souvent sur ce langage.
Un attaquant qui obtient un shell sur l’un de ces serveurs peut remplacer l’adresse de dépôt affichée à la caisse. Il peut aussi injecter un faux formulaire de connexion, ou poser un enregistreur de frappe sur la page de paiement. Les gangs que Sansec suit depuis des années sous le nom de Magecart n’auront même pas besoin de phishing. En effet, le piège s’affichera sur le vrai domaine, avec le vrai certificat. Sansec le dit sans détour : ces failles critiques touchent tous les serveurs web sous PHP 5.4 ou plus récent. La mise à jour de PHP est donc la seule parade, impossible à appliquer depuis le code de la boutique.
Autre mauvaise nouvelle, PHP ne maintient plus que les branches 8.2 et suivantes. Un serveur resté en 8.1 ou en 7.4 n’aura donc pas de correctif officiel. Il faudra alors compter sur un rétroportage de l’hébergeur, ou bien migrer dans la journée.
Correctif PHP à 16h, la liste des choses à faire avant
Inventoriez d’abord. Face à ces failles critiques, Huntress recommande de recenser chaque installation de PHP, y compris celles cachées dans des logiciels tiers. Il faut ensuite isoler d’internet tout ce qui tourne sur une version en fin de vie. Le CERT-EU demande la même chose dans son avis 2026-018, publié lundi soir. Il ajoute une consigne pour ceux qui ne pourront pas patcher à temps : couper du réseau public les applications exposées.
Ensuite, prévenez votre hébergeur dès ce matin pour qu’il se tienne prêt à 16h. Si vous gérez vos serveurs, bloquez le créneau 16h-17h et préparez la commande de mise à jour. Un pare-feu applicatif ne vous sauvera pas forcément, car l’attaque viserait PHP lui-même, avant le code de votre site. Enfin, surveillez vos processus. Une exploitation se verra par un processus php-fpm ou apache2 qui lance soudain un shell ou un curl sans aucune raison.
Le CERT-FR n’avait publié aucune alerte sur ces failles critiques PHP à 7h ce mercredi. En revanche, ses dernières alertes en date visent Ivanti Connect Secure et Citrix NetScaler, sans rapport avec PHP.
Le dernier précédent de cette ampleur s’appelle Log4Shell, en décembre 2021. Une faille d’une bibliothèque Java omniprésente avait alors essuyé des centaines de milliers de tentatives d’attaque en 72 heures. Cette fois, les défenseurs connaissent l’heure exacte du départ. Les protocoles DeFi dont le site peut être détourné via son nom de domaine connaissent déjà le prix d’un front-end compromis. Mise à jour à venir après la publication du correctif des failles critiques PHP à 16h. Elle précisera les versions corrigées et les premiers signes d’exploitation, s’il y en a.
L’article PHP : 2 failles critiques, un correctif et quinze minutes avant les premières attaques est apparu en premier sur Journal du Coin.
