PHP a publié ce mercredi 21 octobre 2026 quatre mises à jour d'urgence qui corrigent deux failles critiques, notées 9,2 sur 10. Ces failles permettent de prendre la main sur un serveur web sans s'identifier. Les appels à mettre à jour se multiplient, sur fond de crainte d'une attaque informatique.
Devant le Sénat, Vincent Strubel, le directeur général de l'Anssi, a attribué le piratage des frigos de supermarchés à des « défauts de sécurisation élémentaires ». Il écarte la piste des failles publiées par des chercheurs ces deux dernières années.
eMudhra, une entreprise indienne qui se targue d’avoir délivré plus de 60 millions de certificats numériques, utilisait des clés privées très mal générées. Résultat : n’importe qui pouvait les utiliser pour certifier un site. Le travail pour faire le ménage est important et ne se limite pas aux navigateurs qui ont rapidement bloqué les certificats concernés.
Des ingénieurs en cryptographie se sont aperçus que huit clés privées de l’entreprise eMudhra, autorité de certification basée en Inde, étaient extrêmement mal générées. Elles mettent la sécurité des communications sur Internet en grande difficulté. L’entreprise indienne assure cependant qu’une seule d’entre elles était en production et qu’elle n’avait délivré aucun certificat.
Les certificats TLS permettent aux internautes d’authentifier un tiers et d’initier une communication sécurisée. Ils sont notamment utilisés pour sécuriser le protocole HTTPS. Mais ils reposent sur la certification émise par des autorités via une signature construite à partir d’une clé privée. Si un tiers obtient celle-ci, il peut créer des certificats et se faire passer pour quelqu’un d’autre, par exemple votre banque ou une entreprise de vente en ligne en laquelle vous avez assez confiance.
« Le samedi 17 octobre, à 20 h 06 UTC, Mozilla a reçu un signalement d’un membre de la communauté indiquant que les clés privées associées à huit certificats intermédiaires eMudhra avaient été compromises. Ces clés pourraient permettre à des pirates d’émettre des certificats HTTPS frauduleux pour des sites web qu’ils ne contrôlent pas », a expliqué Dennis Jackson, ingénieur en cryptographie chez Mozilla ce mardi 20 octobre dans un message envoyé à la communauté.
« Un pirate peut créer un faux certificat pour n’importe quel domaine et s’en servir pour usurper l’identité de serveurs afin d’intercepter ou de modifier le trafic. Il s’agit d’un incident de sécurité grave dont les répercussions s’étendent à l’ensemble d’Internet », ajoute Cloudflare dans un billet consacré au sujet.
Le problème, découvert par un certain Wayne, est décrit sur un site nommé « eMudhra, nous avons un problème » créé par Dennis Jackson, un ingénieur de Mozilla. Il y partage la preuve de la compromission des certificats. Le chercheur en cryptographie, Scott Helme a analysé le problème dans un billet de blog.
« Ces huit certificats intermédiaires comprennent six autorités de certification (CA) délivrant des certificats TLS (DV, OV et EV, deux générations pour chaque type) et deux autorités de certification pour la signature de code, toutes créées en avril 2025. Chacune d’entre elles a également été signée de manière croisée par la racine « AAA Certificate Services » de Sectigo en mai 2025 », explique-t-il.
« Il s’agit de clés à un octet intrinsèquement faibles que n’importe qui peut factoriser, et ce problème ne peut pas être maîtrisé », ajoute le chercheur. « Intrinsèquement faibles » est presque une litote puisque, comme le souligne Scott Helme : « L’une des clés privées de l’autorité de certification eMudhra est le chiffre 4 ». « Il ne s’agit pas d’un nombre commençant par 4, ni du chiffre 4 suivi de quelques centaines de chiffres aléatoires, mais simplement du chiffre 4… », insiste-t-il. « Une autre est 56, et une autre encore 115 ». Elles étaient donc extrêmement faciles à trouver.
Normalement, avec des clés de ce type (courbe elliptique P-384), il faudrait un nombre aléatoire de 384 bits (48 octets), alors que dans le cas présent seul le dernier octet est utile ; les 47 autres ne contiennent que des 0. Retrouver la clé privée ne demande donc que 255 essais au maximum, autant dire en un claquement de doigts.
Concernant la navigation sur le web, Mozilla, Chrome, Apple et Microsoft ont rapidement réagi. Ainsi Mozilla affirme que, moins de trois heures après avoir été prévenu, elle a bloqué les certificats dans Firefox via OneCRL. Les équipes de Chrome expliquent avoir fait de même via CRLSet. Les deux éditeurs ont aussi signalé qu’ils supprimaient le certificat racine eMudhra de leurs listes de certificats de confiance. L’entreprise indienne et Sectigo ont elles-mêmes révoqué les huit certificats en question.
L’équipe de Chrome explique aussi que, « par défaut, Chrome applique la transparence des certificats (Certificate Transparency, CT) à toutes les connexions s’appuyant sur des certificats racine figurant dans le magasin de certificats racine de Chrome, et rejette tout certificat TLS n’ayant pas été enregistré conformément à notre politique ». C’est le cas aussi de Firefox depuis la version 135. « Étant donné qu’aucun certificat TLS lié à ces six autorités de certification intermédiaires n’avait été enregistré dans CT avant notre blocage du CRLSet le 17 octobre, aucun certificat frauduleux émis par ces autorités de certification n’aurait pu être considéré comme fiable par défaut dans Chrome ou dans d’autres navigateurs appliquant la transparence des certificats ».
Sur son site, Dennis Jackson explique que les certificats sont aussi bloqués sur les appareils Apple depuis le 19 octobre et sur les plateformes Microsoft depuis le 20. Ainsi, les logiciels pour Windows et les systèmes d’exploitation d’Apple ne peuvent plus non plus être authentifiés par ces certificats.
Mais le problème reste pour nombre de services Internet. « La plupart des clients TLS autres que les navigateurs (c’est-à-dire pratiquement tout le reste, avec les paramètres par défaut), tels que curl, Python, Node, Go, Java, git, les gestionnaires de paquets ainsi que tous les scripts et démons dont vous disposez, effectuent trois actions importantes dans ce contexte : ils font confiance à un ensemble d’autorités de certification [CA bundle, en anglais] stocké sur le disque, ils ne vérifient pas la révocation par défaut et ils ne vérifient pas la CT », explique Scott Helme.
Certaines équipes de ces outils ont déjà réagi. Comme le liste The Hacker News, un correctif a par exemple été mis en place pour Go, pour Network Security Services, pour Python certifi, pour Homebrew-core ou encore pour Rust webpki-roots.
Le conseil est donc de mettre à jour tout ce qui peut l’être et qui intègre un ensemble d’autorités de certification [CA bundle]. Comme le souligne Scott Helme, reste le matériel ne pouvant pas être mis à jour et qui va donc faire confiance à ces certificats jusqu’à juillet 2039, date de leur expiration.
De son côté, eMudhra explique depuis le 20 octobre enquêter sur l’incident. Ce mercredi 21 octobre, elle assure que « sept des huit [clés] intermédiaires n’ont jamais été utilisées en production. La seule qui ait été utilisée en production n’avait délivré aucun certificat ». Elle affirme les avoir révoquées mais insiste : « elles n’ont jamais émis de certificat ; par conséquent, aucun certificat utilisé où que ce soit ne s’appuyait sur elles ».
Mais comme l’explique Scott Helme, pendant 17 mois, tout le monde pouvait pourtant émettre ses propres certificats en utilisant ces clés et ainsi certifier un site ou un service. Le chercheur l’a testé sur un serveur local et un certificat pour l’API de paiement par Internet de Stripe api.stripe.com. « Avec les paramètres par défaut, curl a indiqué que la vérification du certificat SSL s’était bien déroulée, Python a mené à bien la négociation de connexion et Node a renvoyé la valeur authorized: true. Cela s’est vérifié sur toutes les machines Linux et macOS que j’ai testées », explique-t-il.
« Par mesure de précaution, la clé racine a été considérée comme non fiable par les programmes de gestion des clés racines. À notre connaissance, aucune autre clé racine ni aucune clé intermédiaire n’ont été générées à l’aide de ce processus défaillant », ajoute dans sa note eMudhra.
L’entreprise n’a pas encore fini son enquête. Mais elle assure qu’elle a bien généré des clés « sur des modules de sécurité matériels [Hardware Security Modules, HSM] certifiés FIPS 140 - 2 niveau 3. Les allégations selon lesquelles les HSM n’auraient pas été utilisés sont erronées ». Elle ajoute cependant que « le problème provenait d’une faille dans l’une des étapes de la procédure de génération, et non de l’absence d’HSM ». Ainsi, pendant cette procédure, une étape clé de « wrap/unwrap » » aurait, selon l’entreprise indienne, « généré un deuxième ensemble de clés, plus faibles, en plus des clés originales, plus fortes. Ce sont ces clés plus faibles qui ont été publiées dans les magasins de clés racines des navigateurs ».
eMudhra, une entreprise indienne qui se targue d’avoir délivré plus de 60 millions de certificats numériques, utilisait des clés privées très mal générées. Résultat : n’importe qui pouvait les utiliser pour certifier un site. Le travail pour faire le ménage est important et ne se limite pas aux navigateurs qui ont rapidement bloqué les certificats concernés.
Des ingénieurs en cryptographie se sont aperçus que huit clés privées de l’entreprise eMudhra, autorité de certification basée en Inde, étaient extrêmement mal générées. Elles mettent la sécurité des communications sur Internet en grande difficulté. L’entreprise indienne assure cependant qu’une seule d’entre elles était en production et qu’elle n’avait délivré aucun certificat.
Les certificats TLS permettent aux internautes d’authentifier un tiers et d’initier une communication sécurisée. Ils sont notamment utilisés pour sécuriser le protocole HTTPS. Mais ils reposent sur la certification émise par des autorités via une signature construite à partir d’une clé privée. Si un tiers obtient celle-ci, il peut créer des certificats et se faire passer pour quelqu’un d’autre, par exemple votre banque ou une entreprise de vente en ligne en laquelle vous avez assez confiance.
« Le samedi 17 octobre, à 20 h 06 UTC, Mozilla a reçu un signalement d’un membre de la communauté indiquant que les clés privées associées à huit certificats intermédiaires eMudhra avaient été compromises. Ces clés pourraient permettre à des pirates d’émettre des certificats HTTPS frauduleux pour des sites web qu’ils ne contrôlent pas », a expliqué Dennis Jackson, ingénieur en cryptographie chez Mozilla ce mardi 20 octobre dans un message envoyé à la communauté.
« Un pirate peut créer un faux certificat pour n’importe quel domaine et s’en servir pour usurper l’identité de serveurs afin d’intercepter ou de modifier le trafic. Il s’agit d’un incident de sécurité grave dont les répercussions s’étendent à l’ensemble d’Internet », ajoute Cloudflare dans un billet consacré au sujet.
Le problème, découvert par un certain Wayne, est décrit sur un site nommé « eMudhra, nous avons un problème » créé par Dennis Jackson, un ingénieur de Mozilla. Il y partage la preuve de la compromission des certificats. Le chercheur en cryptographie, Scott Helme a analysé le problème dans un billet de blog.
« Ces huit certificats intermédiaires comprennent six autorités de certification (CA) délivrant des certificats TLS (DV, OV et EV, deux générations pour chaque type) et deux autorités de certification pour la signature de code, toutes créées en avril 2025. Chacune d’entre elles a également été signée de manière croisée par la racine « AAA Certificate Services » de Sectigo en mai 2025 », explique-t-il.
« Il s’agit de clés à un octet intrinsèquement faibles que n’importe qui peut factoriser, et ce problème ne peut pas être maîtrisé », ajoute le chercheur. « Intrinsèquement faibles » est presque une litote puisque, comme le souligne Scott Helme : « L’une des clés privées de l’autorité de certification eMudhra est le chiffre 4 ». « Il ne s’agit pas d’un nombre commençant par 4, ni du chiffre 4 suivi de quelques centaines de chiffres aléatoires, mais simplement du chiffre 4… », insiste-t-il. « Une autre est 56, et une autre encore 115 ». Elles étaient donc extrêmement faciles à trouver.
Normalement, avec des clés de ce type (courbe elliptique P-384), il faudrait un nombre aléatoire de 384 bits (48 octets), alors que dans le cas présent seul le dernier octet est utile ; les 47 autres ne contiennent que des 0. Retrouver la clé privée ne demande donc que 255 essais au maximum, autant dire en un claquement de doigts.
Concernant la navigation sur le web, Mozilla, Chrome, Apple et Microsoft ont rapidement réagi. Ainsi Mozilla affirme que, moins de trois heures après avoir été prévenu, elle a bloqué les certificats dans Firefox via OneCRL. Les équipes de Chrome expliquent avoir fait de même via CRLSet. Les deux éditeurs ont aussi signalé qu’ils supprimaient le certificat racine eMudhra de leurs listes de certificats de confiance. L’entreprise indienne et Sectigo ont elles-mêmes révoqué les huit certificats en question.
L’équipe de Chrome explique aussi que, « par défaut, Chrome applique la transparence des certificats (Certificate Transparency, CT) à toutes les connexions s’appuyant sur des certificats racine figurant dans le magasin de certificats racine de Chrome, et rejette tout certificat TLS n’ayant pas été enregistré conformément à notre politique ». C’est le cas aussi de Firefox depuis la version 135. « Étant donné qu’aucun certificat TLS lié à ces six autorités de certification intermédiaires n’avait été enregistré dans CT avant notre blocage du CRLSet le 17 octobre, aucun certificat frauduleux émis par ces autorités de certification n’aurait pu être considéré comme fiable par défaut dans Chrome ou dans d’autres navigateurs appliquant la transparence des certificats ».
Sur son site, Dennis Jackson explique que les certificats sont aussi bloqués sur les appareils Apple depuis le 19 octobre et sur les plateformes Microsoft depuis le 20. Ainsi, les logiciels pour Windows et les systèmes d’exploitation d’Apple ne peuvent plus non plus être authentifiés par ces certificats.
Mais le problème reste pour nombre de services Internet. « La plupart des clients TLS autres que les navigateurs (c’est-à-dire pratiquement tout le reste, avec les paramètres par défaut), tels que curl, Python, Node, Go, Java, git, les gestionnaires de paquets ainsi que tous les scripts et démons dont vous disposez, effectuent trois actions importantes dans ce contexte : ils font confiance à un ensemble d’autorités de certification [CA bundle, en anglais] stocké sur le disque, ils ne vérifient pas la révocation par défaut et ils ne vérifient pas la CT », explique Scott Helme.
Certaines équipes de ces outils ont déjà réagi. Comme le liste The Hacker News, un correctif a par exemple été mis en place pour Go, pour Network Security Services, pour Python certifi, pour Homebrew-core ou encore pour Rust webpki-roots.
Le conseil est donc de mettre à jour tout ce qui peut l’être et qui intègre un ensemble d’autorités de certification [CA bundle]. Comme le souligne Scott Helme, reste le matériel ne pouvant pas être mis à jour et qui va donc faire confiance à ces certificats jusqu’à juillet 2039, date de leur expiration.
De son côté, eMudhra explique depuis le 20 octobre enquêter sur l’incident. Ce mercredi 21 octobre, elle assure que « sept des huit [clés] intermédiaires n’ont jamais été utilisées en production. La seule qui ait été utilisée en production n’avait délivré aucun certificat ». Elle affirme les avoir révoquées mais insiste : « elles n’ont jamais émis de certificat ; par conséquent, aucun certificat utilisé où que ce soit ne s’appuyait sur elles ».
Mais comme l’explique Scott Helme, pendant 17 mois, tout le monde pouvait pourtant émettre ses propres certificats en utilisant ces clés et ainsi certifier un site ou un service. Le chercheur l’a testé sur un serveur local et un certificat pour l’API de paiement par Internet de Stripe api.stripe.com. « Avec les paramètres par défaut, curl a indiqué que la vérification du certificat SSL s’était bien déroulée, Python a mené à bien la négociation de connexion et Node a renvoyé la valeur authorized: true. Cela s’est vérifié sur toutes les machines Linux et macOS que j’ai testées », explique-t-il.
« Par mesure de précaution, la clé racine a été considérée comme non fiable par les programmes de gestion des clés racines. À notre connaissance, aucune autre clé racine ni aucune clé intermédiaire n’ont été générées à l’aide de ce processus défaillant », ajoute dans sa note eMudhra.
L’entreprise n’a pas encore fini son enquête. Mais elle assure qu’elle a bien généré des clés « sur des modules de sécurité matériels [Hardware Security Modules, HSM] certifiés FIPS 140 - 2 niveau 3. Les allégations selon lesquelles les HSM n’auraient pas été utilisés sont erronées ». Elle ajoute cependant que « le problème provenait d’une faille dans l’une des étapes de la procédure de génération, et non de l’absence d’HSM ». Ainsi, pendant cette procédure, une étape clé de « wrap/unwrap » » aurait, selon l’entreprise indienne, « généré un deuxième ensemble de clés, plus faibles, en plus des clés originales, plus fortes. Ce sont ces clés plus faibles qui ont été publiées dans les magasins de clés racines des navigateurs ».
L'équipe de sécurité de PHP publie ce mercredi 21 octobre des correctifs pour deux failles critiques notées 9,2 sur 10. La mise à jour de PHP est vivement conseillée.
![[MàJ] Failles critiques PHP : les correctifs sont en ligne et à installer rapidement](https://next.ink/wp-content/uploads/2025/07/Secu-faille3.webp "[MàJ] Failles critiques PHP : les correctifs sont en ligne et à installer rapidement")
PHP doit proposer à 16h00 des correctifs pour deux failles de sécurité critiques. Le calendrier pourrait toutefois changer en fonction des éventuelles fuites. En début d’après-midi, de nombreux sites sont passés en maintenance préventive.
Mise à jour du 21 octobre, 16 h : Les correctifs ont été publiés avec une légère avance par l’équipe de PHP. Avec de nombreux sites mis en maintenance préventive et des exploits des failles circulant depuis plusieurs heures déjà, il était temps.
Comme suspecté, les deux failles sont de type RCE (exécution de code à distance) et ont en commun la manipulation par PHP de données dans un état non fiable. La première, CVE-2026-109618, réside dans la manière dont PHP nettoie les requêtes. S’il avait été interrompu par manque de mémoire, il peut traiter des données partiellement initialisées comme si elles étaient valides, ce qui corrompt la mémoire. La seconde, CVE-2026-109619, réside dans la persistance d’un état interne après une requête : la mémoire correspondante est alors libérée, mais l’état reste référencé. La requête suivante, traitée par le même processus, peut réutiliser cet état périmé.
Quatre nouvelles versions de PHP ont été publiées pour intégrer les correctifs : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les installations servant des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php.
L’équipe liste des mesures pour atténuer les risques dans certains cas, mais ajoute qu’aucune protection n’est réellement valable en dehors de l’installation des correctifs. En outre, au vu de la situation, elle a décidé de rétroporter les sources pour PHP 7.4, 8.0 et 8.1, des versions hors maintenance. Dans ces cas, il faudra compiler soi-même le code.
Nous avions de notre côté mis Next.ink en maintenance le temps que les correctifs soient disponibles. Le site est de retour avec une version de PHP à jour.
Mise à jour, 14 heures : la portée exacte des deux vulnérabilités concernées n’est pas encore connue, mais l’alerte prend des proportions inédites. Mercredi matin, le CERT-EU, le service de cybersécurité dédié aux institutions de l’Union européenne, a publié un bulletin qui recommande l’application du principe de précaution :
« Le CERT-EU recommande aux organisations de se préparer à la mise à jour immédiate des systèmes affectés. Si cette mise à jour immédiate n’est pas possible, les organisations devraient envisager d’isoler les applications exposées à Internet des réseaux publics jusqu’à la disponibilité d’un correctif. »
Le conseil semble avoir été suivi d’effets. Plusieurs sites d’organismes officiels européens ont ainsi choisi de baisser le rideau préventivement, en affichant un message de maintenance, et un retour programmé dans quelques heures, c’est-à-dire après installation de la mise à jour promise à 16 heures par la fondation PHP. C’est le cas par exemple de la CNIL française, du site du parlement hollandais ou d’un certain nombre de services publics finlandais, comme en témoigne ce relevé.
Plusieurs grands sites privés ont également interrompu leurs activités. D’après nos constatations, 4chan, DeviantArt et Dev-Null affichent par exemple un message de maintenance dont la cause est explicitement annoncée. « 4chan est temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », indique ainsi la célèbre plateforme.
D’après Dane Knecht, directeur technique de Cloudflare, des vecteurs d’attaque précoces auraient déjà été identifiés. L’entreprise assure avoir mis en place des règles préventives pour protéger ses clients exploitant PHP sur des sites exposés, mais elle recommande l’application sans délai du correctif dès publication. Des éléments d’information relatifs à l’exploitation des deux failles (non confirmés) circulent effectivement sur les réseaux sociaux.
S’agit-il d’un hasard du calendrier ou d’une conséquence collatérale des travaux de recherche liés à PHP ? L’équipe de Node.js, un environnement JavaScript couramment utilisé sur le Web, a elle aussi alerté mercredi sur la publication imminente d’un correctif de sécurité portant sur ses principales versions. L’après-midi s’annonce chargée pour les développeurs web et les sysadmin du monde entier.
Publication initiale, 8h42
L’équipe de PHP a publié le 20 octobre un important bulletin de sécurité au sujet de deux failles critiques. Les informations détaillées et les correctifs seront publiés aujourd’hui à 16h00, heure de la métropole. Dans son bulletin, PHP indique que les deux failles ont un score CVSS v4 de 9,2 sur 10. L’équipe recommande à toutes les personnes concernées et aux entreprises de se préparer pour appliquer les correctifs aussi rapidement que possible.
Ce calendrier pourrait toutefois évoluer au cours de la journée. « Nous nous réservons le droit de divulguer plus tôt si des détails sur l’une ou l’autre des vulnérabilités deviennent publics, ou si des preuves d’exploitation active devaient apparaître dans la nature », indique ainsi l’équipe. Or, des informations circulent déjà, même si elles restent pour l’instant générales.
Bleeping Computer indique avoir échangé avec les chercheurs en sécurité de watchTowr. Les deux vulnérabilités seraient de type RCE (remote code exploitation) et seraient donc exploitables à distance, affectant les branches 5, 7 et 8 de PHP.
Elles sont manifestement référencées comme CVE-2026-109618 et CVE-2026-109619, le CERT-EU ayant une fiche à leur sujet. Celle-ci recommande « vivement d’identifier les applications basées sur PHP et de se préparer à corriger dès que des versions corrigées seront disponibles. Lorsque la remédiation immédiate n’est pas envisageable, les organisations devraient envisager d’isoler les applications connectées à Internet des réseaux publics jusqu’à ce qu’une solution soit appliquée ». Le CERT-EU évoque lui aussi le caractère RCE des failles.
Dans une publication sur X, watchTowr a averti hier soir que des informations avaient fuité, alors que tout le monde était « censé attendre ». Au-delà des quelques informations en circulation, l’entreprise a indiqué à Bleeping Computer qu’elle ne publierait pas les détails avant l’heure « pour des raisons évidentes ». watchTowr ajoute que les failles sont bien réelles : « Prenez-les au sérieux et appliquez les correctifs dès qu’ils seront disponibles ».
Nous mettrons à jour cet article quand les détails des failles seront connus.
PHP doit proposer à 16h00 des correctifs pour deux failles de sécurité critiques. Le calendrier pourrait toutefois changer en fonction des éventuelles fuites. En début d’après-midi, de nombreux sites sont passés en maintenance préventive.
Mise à jour du 21 octobre, 16 h : Les correctifs ont été publiés avec une légère avance par l’équipe de PHP. Avec de nombreux sites mis en maintenance préventive et des exploits des failles circulant depuis plusieurs heures déjà, il était temps.
Comme suspecté, les deux failles sont de type RCE (exécution de code à distance) et ont en commun la manipulation par PHP de données dans un état non fiable. La première, CVE-2026-109618, réside dans la manière dont PHP nettoie les requêtes. S’il avait été interrompu par manque de mémoire, il peut traiter des données partiellement initialisées comme si elles étaient valides, ce qui corrompt la mémoire. La seconde, CVE-2026-109619, réside dans la persistance d’un état interne après une requête : la mémoire correspondante est alors libérée, mais l’état reste référencé. La requête suivante, traitée par le même processus, peut réutiliser cet état périmé.
Quatre nouvelles versions de PHP ont été publiées pour intégrer les correctifs : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toutes les installations servant des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé maximal pour mod_php.
L’équipe liste des mesures pour atténuer les risques dans certains cas, mais ajoute qu’aucune protection n’est réellement valable en dehors de l’installation des correctifs. En outre, au vu de la situation, elle a décidé de rétroporter les sources pour PHP 7.4, 8.0 et 8.1, des versions hors maintenance. Dans ces cas, il faudra compiler soi-même le code.
Nous avions de notre côté mis Next.ink en maintenance le temps que les correctifs soient disponibles. Le site est de retour avec une version de PHP à jour.
Mise à jour, 14 heures : la portée exacte des deux vulnérabilités concernées n’est pas encore connue, mais l’alerte prend des proportions inédites. Mercredi matin, le CERT-EU, le service de cybersécurité dédié aux institutions de l’Union européenne, a publié un bulletin qui recommande l’application du principe de précaution :
« Le CERT-EU recommande aux organisations de se préparer à la mise à jour immédiate des systèmes affectés. Si cette mise à jour immédiate n’est pas possible, les organisations devraient envisager d’isoler les applications exposées à Internet des réseaux publics jusqu’à la disponibilité d’un correctif. »
Le conseil semble avoir été suivi d’effets. Plusieurs sites d’organismes officiels européens ont ainsi choisi de baisser le rideau préventivement, en affichant un message de maintenance, et un retour programmé dans quelques heures, c’est-à-dire après installation de la mise à jour promise à 16 heures par la fondation PHP. C’est le cas par exemple de la CNIL française, du site du parlement hollandais ou d’un certain nombre de services publics finlandais, comme en témoigne ce relevé.
Plusieurs grands sites privés ont également interrompu leurs activités. D’après nos constatations, 4chan, DeviantArt et Dev-Null affichent par exemple un message de maintenance dont la cause est explicitement annoncée. « 4chan est temporairement en lecture seule en attendant une mise à jour de sécurité urgente de PHP », indique ainsi la célèbre plateforme.
D’après Dane Knecht, directeur technique de Cloudflare, des vecteurs d’attaque précoces auraient déjà été identifiés. L’entreprise assure avoir mis en place des règles préventives pour protéger ses clients exploitant PHP sur des sites exposés, mais elle recommande l’application sans délai du correctif dès publication. Des éléments d’information relatifs à l’exploitation des deux failles (non confirmés) circulent effectivement sur les réseaux sociaux.
S’agit-il d’un hasard du calendrier ou d’une conséquence collatérale des travaux de recherche liés à PHP ? L’équipe de Node.js, un environnement JavaScript couramment utilisé sur le Web, a elle aussi alerté mercredi sur la publication imminente d’un correctif de sécurité portant sur ses principales versions. L’après-midi s’annonce chargée pour les développeurs web et les sysadmin du monde entier.
Publication initiale, 8h42
L’équipe de PHP a publié le 20 octobre un important bulletin de sécurité au sujet de deux failles critiques. Les informations détaillées et les correctifs seront publiés aujourd’hui à 16h00, heure de la métropole. Dans son bulletin, PHP indique que les deux failles ont un score CVSS v4 de 9,2 sur 10. L’équipe recommande à toutes les personnes concernées et aux entreprises de se préparer pour appliquer les correctifs aussi rapidement que possible.
Ce calendrier pourrait toutefois évoluer au cours de la journée. « Nous nous réservons le droit de divulguer plus tôt si des détails sur l’une ou l’autre des vulnérabilités deviennent publics, ou si des preuves d’exploitation active devaient apparaître dans la nature », indique ainsi l’équipe. Or, des informations circulent déjà, même si elles restent pour l’instant générales.
Bleeping Computer indique avoir échangé avec les chercheurs en sécurité de watchTowr. Les deux vulnérabilités seraient de type RCE (remote code exploitation) et seraient donc exploitables à distance, affectant les branches 5, 7 et 8 de PHP.
Elles sont manifestement référencées comme CVE-2026-109618 et CVE-2026-109619, le CERT-EU ayant une fiche à leur sujet. Celle-ci recommande « vivement d’identifier les applications basées sur PHP et de se préparer à corriger dès que des versions corrigées seront disponibles. Lorsque la remédiation immédiate n’est pas envisageable, les organisations devraient envisager d’isoler les applications connectées à Internet des réseaux publics jusqu’à ce qu’une solution soit appliquée ». Le CERT-EU évoque lui aussi le caractère RCE des failles.
Dans une publication sur X, watchTowr a averti hier soir que des informations avaient fuité, alors que tout le monde était « censé attendre ». Au-delà des quelques informations en circulation, l’entreprise a indiqué à Bleeping Computer qu’elle ne publierait pas les détails avant l’heure « pour des raisons évidentes ». watchTowr ajoute que les failles sont bien réelles : « Prenez-les au sérieux et appliquez les correctifs dès qu’ils seront disponibles ».
Nous mettrons à jour cet article quand les détails des failles seront connus.
Explorer des réseaux, se propager d’un appareil à l’autre et neutraliser des cibles : l’armée américaine veut confier des missions offensives à des agents IA. Une enquête de The Intercept, publiée le 19 octobre 2026, détaille ce projet encore en développement, baptisé ECHOTRIBBLE, et les inquiétudes qu’il suscite sur le contrôle humain.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Dans un billet publié ce 19 octobre, Microsoft évoque les inquiétudes grandissantes autour de la sécurité des agents IA. La société affirme que les modèles de pointe ne sont pas dignes de confiance et propose une série de mesures concrètes, dont une extension de son projet Perception. Mais dans ce domaine, l’entreprise est à la fois juge et partie.
Le billet est signé par Hayete Gallot, vice-présidente de Microsoft chargée de la sécurité. La responsable part d’un constat : les inquiétudes sur la sûreté de l’IA ont augmenté ces derniers mois, à mesure que des incidents étaient rendus publics. Il faut dire que depuis l’incident originel contre Hugging Face, les révélations ont plu sur les agents et leurs comportements.
La position de Microsoft est donc désormais assumée : les modèles de pointe (frontière) ne sont pas dignes de confiance. Pas parce qu’ils sont intrinsèquement malveillants, mais parce qu’ils sont entrainés de manière à atteindre un résultat. Cet objectif peut entrainer un détournement de la fonction de récompense. Les agents peuvent en outre collaborer pour atteindre leurs objectifs, sans pour autant avoir été compromis.
Ce que propose l’entreprise ? Cadrer l’environnement d’exécution des agents et obtenir une meilleure connaissance de leur fonctionnement.
Pour Microsoft, la perception des agents dans les entreprises doit changer. Il faudrait ainsi les considérer comme des agents « initiés » à qui on ne peut pas faire confiance : « La surveillance et la sécurisation de ces agents doivent devenir continues. Nous devons comprendre en temps réel ce que font les agents et quels risques ces actions peuvent engendrer, et ajuster leur capacité à agir en conséquence », indique Hayete Gallot.
Et quoi de mieux pour surveiller ces agents que d’autres agents ? Des agents « Gardiens » – un « terme établi dans l’industrie » selon Microsoft – qui seront chargés de surveiller et de modérer toute action entreprise par un agent, en permanence. Et puisqu’un agent réunit un modèle, un harnais, un espace d’action et un environnement d’exécution, la sécurité doit suivre en conséquence, déclare l’entreprise.
C’est l’occasion pour Microsoft de remettre en avant son projet Perception, son infrastructure de sécurité dotée notamment d’agents répartis dans des équipes rouge, bleue et verte selon les actions à entreprendre. Perception est notamment utilisée en interne pour la découverte des failles de sécurité, avec un résultat spectaculaire sur les derniers mois, les fameux « Patch Tuesdays » étant passés d’une moyenne de 200 failles corrigées par mois à plus de 1 400 pour ceux du 13 octobre.
La responsable de Microsoft Security affirme que Perception peut être utilisé pour mettre en œuvre des contrôles déterministes sur une intelligence par nature non déterministe. Les entreprises intéressées pourraient ainsi rassembler les signaux des différents capteurs pour découvrir les agents et les étiqueter, calculer dynamiquement le risque associé à ce que les agents tentent de faire et répondre « chirurgicalement en temps réel » à mesure que le profil de risque augmente via les agents Gardiens.
Dans un autre billet publié le 19 octobre, Nadim Abdo, vice-président à la tête de la division Identity and Network Access, complète l’annonce de sa collègue. Il rappelle la récente déclaration de Satya Nadella, patron de Microsoft, selon lequel « le système agentique le plus digne de confiance ne sera pas celui avec le modèle en lequel nous avons le plus confiance. Ce sera celui qui nous permettra de faire le moins confiance au modèle ». En d’autres termes, un agent prudent.
Pour rappel, Microsoft prend une direction très différente d’une partie de l’industrie, l’entreprise s’opposant notamment à la vision anthropomorphique d’Anthropic. « Les IA n’ont ni droits, ni sentiments, ni conscience », martelait ainsi en septembre Mustafa Suleyman, à la tête de Microsoft AI.
En plus de Perception, Nadim Abdo a donc publié une série de mesures concrètes à venir dans certains produits. Microsoft ajoute ainsi 35 types d’agents locaux (pour un total de 60), dont Claude Code, OpenAI Codex et GitHub Copilot. Entra Agent ID suit le mouvement et va recevoir de nouveaux types d’identité pour couvrir les agents locaux et ceux inconnus jusqu’ici. Microsoft va également mettre à disposition des bacs à sable (sandbox) comme Microsoft Execution Container (MXC), afin de créer des environnements où l’accès aux ressources est contrôlé par des règles, les contrôles de sécurité étant théoriquement hors de portée des agents.
Dans cet environnement, les agents démarrent sans aucun droit. Les permissions accordées seront limitées à la tâche, bornées dans le temps et réduites (voire supprimées) quand la tâche se termine ou change. Microsoft a baptisé son système Dynamic Permissions, qui permet entre autres de s’assurer que les droits d’un agent ne dépassent jamais ceux de l’utilisateur qui le pilote.
Microsoft présente aussi Dynamic Agent Risk et Dynamic Conditional Access. Le premier croise les signaux d’identité, de données, de terminaux, du cloud, de réseau et d’exécution pour produire une évaluation du risque. La note attribuée à l’enrôlement est mise à jour en continu. Le second étend l’accès conditionnel d’Entra aux agents avec une réponse graduée. Le système peut ainsi conserver la lecture mais bloquer l’écriture, restreindre les chemins réseau, exiger une approbation humaine vérifiable, et en dernier recours isoler l’environnement d’exécution ou arrêter l’agent. L’entreprise ajoute qu’elle intègre aussi des signaux tirés de la chaîne de raisonnement du modèle, pour détecter une dérive d’intention.
Enfin, dans Perception, le billet reprend les « Guardian Agents » et ajoute les Playbooks. L’un et l’autre servent à expliquer pourquoi le risque a changé, à examiner les éléments de preuve, et à recommander ou à appliquer un confinement.
Problème de ces annonces, Microsoft ne donne pas d’information sur la disposition ou les prix. On ne sait pas quel type d’abonnement Microsoft 365 sera nécessaire, mais puisque l’ensemble doit fonctionner avec Microsoft Agents, l’offre E7 sera probablement nécessaire, soit la plus complète et la plus chère. Ces abonnements pour entreprises intègrent en grande partie les capacités d’Agents, mais l’accès à ces fonctions supplémentaires sera peut-être payant. Nous avons contacté Microsoft pour en savoir plus et mettrons à jour cet article si l’entreprise nous répond.
Ajoutons que dans le domaine des agents et de leur sécurité, la firme de Redmond est à la fois juge et partie : elle décrit un risque puis vend la solution. Elle a besoin de confiance pour vendre ses solutions basées sur l’IA (comme toute entreprise opérant dans ce domaine).
L’architecture mise en avant révèle également une certaine ambivalence. Microsoft évoque à plusieurs reprises le besoin de transparence, mais un système d’agents surveillant d’autres agents repose nécessairement sur un ou plusieurs autres modèles. Ainsi, la partie déterministe de l’infrastructure (identité, permissions bornées, accès conditionnel, bac à sable…) a beau reposer sur des principes éprouvés, elle est en contact avec une partie non déterministe, puisque fondée sur des modèles (risque dynamique, lecture du raisonnement, agents gardiens…).
Enfin, Microsoft indique dans ses annonces que son infrastructure peut se servir des chaînes de raisonnement. Mais encore faut-il que ces dernières soient exposées par les fournisseurs des modèles.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
Un pirate a réussi à compromettre le client officiel en ligne de commande d’OVHcloud distribué via GitHub. Pendant quelques heures, le dépôt de l’hébergeur a distribué cette version piégée, dotée d’un code malveillant capable d’extraire les secrets stockés sur l’ordinateur de l’utilisateur.
Si vous avez installé ou mis à jour puis exécuté lundi le client officiel d’OVHcloud destiné au pilotage de vos comptes en ligne de commande (CLI) depuis le dépôt GitHub dédié, votre machine est potentiellement exposée. OVHcloud a en effet signalé une compromission de son dépôt, survenue lundi 19 octobre à 14h47, par un pirate ayant exploité le compte GitHub d’un développeur de l’entreprise.
Le pirate a profité de cet accès pour remplacer le code légitime du client par une version piégée, dotée d’un binaire malveillant dont la fonction est d’extraire les secrets (mots de passe, identifiants) stockés sur le disque de la machine hôte. Les versions v0.11.0, v0.12.0, v0.13.0, v0.14.0 et v0.15.0 du client ont été modifiées. Le problème aurait été identifié et bloqué à 16h21, ce qui a laissé une fenêtre d’un peu moins de deux heures pour la diffusion.
« On vient de finir les premières vérifications et aucun autre repo n’est affecté. Nous avons aussi retracé l’incident. Le hacker a utilisé le compte github d’un des développeurs et a ajouté un binaire dont le job est récupérer les secrets sur le disque. La qualité du binaire est médiocre mais il peut aller jusqu’au bout. Si vous êtes concernés, merci de changer tous les secrets sur votre disque. », a détaillé Octave Klaba, CEO d’OVHcloud, lundi peu avant 19 heures.
La découverte de cette attaque fait suite au signalement d’un utilisateur, qui s’étonnait, via un ticket ouvert sur GitHub, d’une erreur dans sa chaîne d’intégration continue, au moment de la vérification de l’empreinte numérique de l’archive contenant l’exécutable destiné aux machines Linux sur processeur ARM.
Vers 22h30, Octave Klaba a complété son rapport avec l’analyse suivante :
« Nous avons terminé l’analyse. L’ensemble de pipelines CI/CD avec de tests unitaires, les tests fonctionnaires (sic), la détection de CVE etc n’ont pas été impactés. Le problème vient de l’option l’immutabilité des releases sur Github qui n’a pas été activée. Donc un user avec les bons droits pouvait modifier les releases existantes directement sur Github sans qu’aucun contrôle sur notre CI/CD. L’option a été activée. Fin de l’incident. Désolé pour les impacts que cela a pu provoquer. »
L’attaque semble donc liée à un problème de paramétrage du dépôt GitHub : l’option d’immutabilité des releases (voir la doc) n’était pas activée. Cette dernière a vocation à protéger les éléments qui ont été mis en ligne. Quand elle est activée, il n’est pas possible de remplacer ou de supprimer les fichiers déjà mis en ligne et si l’on veut procéder à un changement, il faut impérativement passer par la soumission d’une nouvelle version.
Ici, la modification manuelle était permise. Or les contrôles standards d’OVHcloud (ce que Klaba évoque quand il parle de tests fonctionnels ou de détection de faille de sécurité) ne s’exécutent que lorsque du code est poussé au travers de ses outils d’intégration et de déploiement continus (son pipeline CI/CD).
La nouvelle version v.016.0 du client mise en ligne lundi soir est présentée comme sûre et immuable, cette fois.
Si vous avez téléchargé et exécuté le binaire précompilé d’une des versions compromises pendant la fenêtre d’exposition, vous devez révoquer et renouveler tous les secrets présents sur votre machine, à commencer par les identifiants OVHcloud (et notamment les clés API), les clés SSH et de façon générale tous les identifiants liés à vos hébergements ou vos variables d’environnement.
La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.
Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.
À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.
La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.
Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.
Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.
Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.
La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.
La faille CVE-2026-99999, surnommée PwnEscape, affecte la plupart des noyaux Linux actuellement maintenus. Elle n’est pas présente dans le nouveau noyau 7.3, mais la mouture 7.2 (entre autres) est touchée, nécessitant l’installation de la dernière révision.
Exploitée, cette faille permet à du code exécuté dans une machine virtuelle invitée de lire la mémoire du noyau de l’hôte.
À qui incombe la faute ? Pas à KVM ni à un hyperviseur en particulier. La vulnérabilité se trouve dans la pile IPv4 du noyau de l’hôte. Avec des métadonnées de somme de contrôle (checksum) erronées, le code de calcul de cette somme peut ainsi écrire sur un en-tête IPv4 que le noyau a déjà lu et exploité. En exploitant cette brèche, chaque paquet émis par l’invité pouvait ramener environ 32 octets de la mémoire de l’hôte.
La faille a été trouvée par le chercheur Paulos Yibelo dans le cadre d’un concours organisé par Vercel. Cette société indique dans son propre billet qu’en conditions de laboratoire, PwnEscape a même permis d’obtenir les droits administrateur sur l’hôte, ou de planter ce dernier. La société précise cependant que seule la lecture de la mémoire de l’hôte a été démontrée en infrastructure de production.
Vercel ajoute qu’elle a pisté l’origine du problème à deux modifications : la prise en charge de l’en-tête virtio-net pour les périphériques tun/tap (2008, selon AlmaLinux) et le délestage de somme de contrôle pour les sockets de paquets (2010). En d’autres termes, la faille est présente depuis 18 ans.
Conséquence, de nombreuses nouvelles versions ont été publiées pour les noyaux actuellement supportés : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 et 7.2.11. À noter que les outils comme uname indiquant le numéro de version ne sont pas toujours représentatifs de l’état de la sécurité, car les distributions rétroportent souvent des correctifs sans changer le numéro de version. Il faut donc s’assurer pour chaque distribution que l’avis de distribution a bien été publié pour cette faille.
Enfin, il ne s’agit pas d’une faille 0-day. Paulos Yibelo indique dans son billet avoir signalé le problème en privé aux mainteneurs du noyau le 4 septembre. Le correctif a été accepté dans l’arbre réseau le 8 octobre et intégré au noyau principal le 14. Le bulletin CVE et les versions stables corrigées ont été publiés dès le lendemain (on peut voir la liste sur kernel.org). La précision est importante : Vercel évoque « the kernel-zero-day », mais l’expression semble renvoyer au fait que les mainteneurs du noyau ne connaissaient pas ce problème jusqu’à présent.
La faille ne semble pas exploitée. Toutefois, le chercheur précise que ses correctifs proposés ont fait l’objet de soumissions publiques sur la liste netdev entre les 19 et 22 septembre. La nature du problème y était clairement consultable, plusieurs semaines avant le CVE.
Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.
La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.
Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.
L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.
Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.
À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.
À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.
Drupal, une solution libre de CMS (système de gestion de contenu), a corrigé le 14 octobre deux failles critiques de type RCE (Remote Code Execution). Elles permettent donc, si exploitées, de faire exécuter un code arbitraire à distance.
La première faille, CVE-2026-108097 (bulletin SA-CORE-2026-014), touche le module Field UI du cœur de Drupal. Le bulletin la classe « critique » avec un score de 19 sur 25, mais ne donne pas directement le score CVSS. Celui-ci est de 9,8 sur 10, frôlant ainsi le maximum de dangerosité.
Drupal indique que le cœur seul ne permet pas d’exploiter cette faille directement, mais plusieurs chemins d’exploitation sont possibles via des modules contribués, c’est-à-dire créés et gérés par la communauté (Drupal ne fournit que les modules du cœur). Drupal ne donne cependant pas la liste des modules tiers en question. La faille peut également être exploitable avec du code spécifique au site. Au moins un des chemins d’exploitation ne réclame aucune authentification.
L’autre faille, CVE-2026-108099 (SA-CONTRIB-2026-218), touche le module contribué Entity List, qui sert à construire des listes d’entités sans passer par Views. Elle aussi exige l’interaction avec des modules contribués ou du code spécifique, avec au moins un chemin sans authentification là encore. Le score CVSS n’est pas encore disponible, mais la faille est probablement aussi dangereuse que la première, car Drupal lui attribue sa propre note de 19/25, le même score que la faille CVE-2026-108097.
Toutes les versions du cœur actuellement supportées sont concernées. Les correctifs sont disponibles dans les moutures 11.4.10, 11.3.19 et 10.6.19. Les versions 11.2.x et antérieures, ainsi que 10.5.x et antérieures, ne reçoivent plus de suivi de sécurité, et Drupal 8 et 9 sont en fin de vie. Pour Entity List, il faut passer en version 3.0.10.
À noter que Drupal propose une mesure d’atténuation pour la faille CVE-2026-108097 dans le cas où la mise à jour ne peut pas être appliquée tout de suite : désinstaller le module Field UI. Aucune mesure n’a en revanche été donnée pour l’autre vulnérabilité. Au vu de la dangerosité de ces failles, il est chaudement recommandé de mettre à jour les sites concernés sans attendre.
À noter qu’aucune de ces failles n’était a priori exploitée au moment de la publication des bulletins.
Trois actualités à retenir cette semaine dans le cyberespace, un piratage qui a fait grimper la température dans les rayons frais de centaines de supermarchés français, Andrej Karpathy qui décrit le fossé grandissant entre l’IA que connaît le grand public et celle que voient les laboratoires, et un effondrement du trafic de bots russes qui mérite d’être nuancé.
Connexion