Une semaine difficile pour les défenseurs : PwnEscape, eMudhra, SafePay et le correctif PHP

Mise à jour, 21 octobre, 16h30 heure de Paris : PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 vers 15h35 heure de Paris, légèrement en avance sur les 14h00 UTC annoncées, corrigeant les deux failles critiques, avec en plus des rétroportages au niveau du code source pour 7.4, 8.0 et 8.1. La section PHP ci-dessous a été mise à jour.

Si vous travaillez dans la sécurité, l’administration système ou l’hébergement, les sept jours qui s’achèvent aujourd’hui sont du genre que les gens du métier décrivent platement, par une plage de dates, parce que les adjectifs paraissent peu professionnels. Une évasion critique de machine virtuelle Linux jeudi. Une autorité de certification dont les clés privées se sont révélées récupérables par n’importe qui avec un ordinateur portable, pendant le week-end. Un avis gouvernemental conjoint mardi sur un rançongiciel qui remet les appareils de sauvegarde en configuration d’usine, plus une panne cloud qui a empêché des cartes bancaires de fonctionner, plus l’annonce du projet PHP que deux correctifs critiques arriveraient le lendemain. Ce lendemain, c’est aujourd’hui. Les correctifs étaient annoncés pour 14h00 UTC et sont arrivés un peu en avance, vers 15h35 heure de Paris.

Une rectification compte plus que n’importe quel titre pris isolément. Vous avez peut-être lu que « de nombreux hébergeurs ont été piratés » via l’évasion de VM, surnommée PwnEscape. Au 21 octobre à 13h30 heure de Paris, c’est une crainte, pas un fait confirmé. Aucune exploitation dans la nature n’a été signalée où que ce soit. La crainte a un fondement rationnel, que nous allons expliquer, mais elle doit être étiquetée comme une crainte. Le reste de cet article parcourt la semaine dans l’ordre, sépare ce qui est confirmé de ce qui est pronostiqué, et se termine par la courte liste de ce qu’un lecteur ordinaire ou le propriétaire d’un petit site devrait réellement faire.

Pourquoi les équipes de sécurité sont-elles si usées ?

Commençons par les personnes, car chaque événement de cette semaine a atterri sur les mêmes bureaux. La ISC2 2025 Cybersecurity Workforce Study, publiée en décembre 2025 à partir d'un terrain mené en juillet et août 2025 auprès de 16 029 répondants, a constaté que 48 % des professionnels de la sécurité se sentent épuisés à force d'essayer de rester à jour sur les menaces et les technologies, que 47 % se sentent souvent débordés par leur charge de travail, et que 32 % se sentent surmenés à cause du manque d'effectifs. L'argent n'adoucit pas grand-chose : 20 % n'ont reçu aucune augmentation de salaire durant l'année écoulée, et une rémunération insuffisante était une source fréquente d'insatisfaction pour 31 %.

Le constat le plus acéré concerne la direction. Seuls 32 % des répondants disent que leur organisation traite la cybersécurité comme une fonction métier critique, et 23 % citent cet écart comme une cause d'insatisfaction. Le travail de sécurité est structurellement invisible : un trimestre calme ressemble, vu du conseil d'administration, exactement à une dépense inutile, et la personne qui a empêché dix incidents figure au budget à côté de celle qui a conclu dix ventes. La même étude ISC2 a constaté que 36 % des organisations ont réduit leurs budgets sécurité en 2025 et que 24 % ont signalé des licenciements dans la sécurité, tandis que 72 % des professionnels s'accordent à dire que réduire les effectifs de sécurité augmente significativement le risque d'intrusion.

Les données européennes ne sont pas plus tendres. Dans le State of Cybersecurity 2026 de l'ISACA (terrain en mai 2026 ; 494 répondants européens sur 1 888 dans le monde), 72 % ont déclaré que le métier est plus stressant qu'il y a cinq ans, avec la complexité de l'environnement de menaces (72 %) et des attentes irréalistes combinées à une charge de travail excessive (57 %) comme causes principales. Plus de la moitié des organisations européennes se disent en sous-effectif (56 %) et sous-financées (55 %), et 21 % des entreprises ne prennent aucune mesure contre l'épuisement professionnel. Gardez ces chiffres en tête pendant que la semaine se déroule.

Qu'est-ce que PwnEscape, et des hébergeurs ont-ils vraiment été piratés par ce biais ?

Le jeudi 15 octobre, le projet du noyau Linux a publié CVE-2026-99999, vite surnommée PwnEscape : une faille dans le traitement des sommes de contrôle IPv4 du noyau, notée 9,3 Critique par le CNA du noyau (Red Hat la classe Importante). Le scénario : une micro-VM malveillante envoie des métadonnées de somme de contrôle virtio-net forgées à l'interface TAP de l'hôte. Une évasion invité vers hôte, c'est le moment où une machine virtuelle louée cesse d'être locataire et devient propriétaire : du code à l'intérieur de la VM d'un client prend de l'emprise sur le serveur physique qui fait tourner celles de tous les autres. C'est pourquoi un 9,3 sur des hôtes de type KVM a poussé le personnel des hébergeurs à se resservir du café.

Voici ce qui est réellement établi. La faille a été découverte par des chercheurs de pwn.ai pendant le challenge Sandbox de Vercel, signalée au noyau le 4 septembre, et corrigée dans la branche principale le 14 octobre, avec sept branches stables rectifiées. La fuite de mémoire de l'hôte a été démontrée contre les bacs à sable de production de l'hôte du challenge, comme le confirme le propre compte rendu du challenge par Vercel ; le même billet indique qu'aucun rapport n'a montré quiconque accédant à des données clients dans Vercel Sandbox. Les plantages de l'hôte et l'accès root sur l'hôte n'ont été démontrés que sur les propres machines des chercheurs, et pwn.ai précise que ses travaux ne constituent pas une affirmation d'exécution de commandes root dans l'environnement de production d'un quelconque fournisseur. Le motif de code vulnérable remonte à environ 2008, selon l'analyse de TuxCare.

Et l'exploitation ? L'enrichissement du dossier CVE par la CISA le dit sans détour : Exploitation : none (aucune). La faille ne figure pas dans le catalogue des Known Exploited Vulnerabilities de la CISA au flux du 20 octobre. Aucune attaque confirmée dans la nature n'a été rapportée par aucun des médias qui suivent le dossier. Des chercheurs cités par CSO et heise s'attendent à des exploits fonctionnels contre les configurations les plus faibles d'ici quelques semaines, ce qui est un pronostic, pas une observation.

Alors pourquoi cette angoisse ? Trois raisons, toutes légitimes. D'abord, il n'existe aucun indicateur de compromission publié pour cette faille, aucun hachage malveillant ni infrastructure d'attaquant à rechercher ; SOC Prime note que la détection dépend de la télémétrie de l'hôte, de la supervision de la virtualisation et de l'analyse des plantages, ce que beaucoup de petits hébergeurs ne collectent tout simplement pas. Cela rend la détection difficile. Cela ne rend pas la faille indétectable : aucune source que nous avons trouvée ne dit que l'exploitation ne laisse aucune trace. Ensuite, le correctif exige de patcher et de redémarrer le noyau de l'hôte ; mettre à jour votre propre VM ne sert à rien, si bien que chaque fournisseur concerné fait face à une campagne de redémarrage sur l'ensemble de son parc. Enfin, l'incertitude cause déjà des dégâts commerciaux : un hébergeur japonais a gelé les nouvelles inscriptions sur ses offres VPS, mutualisées et dédiées le 16 octobre par précaution, sans qu'aucune intrusion ne soit signalée, et un hébergeur allemand redémarre ses serveurs de virtualisation depuis le week-end. Pour les clients, le conseil de heise reste valable : vous n'avez rien à faire, hormis vérifier que votre VM est bien revenue en ligne après le redémarrage de votre hébergeur.

Que s'est-il passé avec les certificats eMudhra ?

Samedi est arrivée l'histoire des certificats, et le mot « détournés » a commencé à circuler. La réalité, documentée dans le rapport de bug de Mozilla, est différente et, à certains égards, plus étrange : huit certificats d'autorité de certification intermédiaires appartenant à eMudhra, une autorité de certification indienne, avaient des clés privées P-384 si faibles qu'elles étaient trivialement récupérables. Le personnel de Mozilla lui-même a récupéré les clés quelques heures après le signalement du 17 octobre. eMudhra attribue la faiblesse à un script de génération de clés défectueux utilisé lors d'une cérémonie de clés en avril 2025, invoquant des erreurs humaines à plusieurs étapes.

Ce qui a suivi, c'est l'écosystème de confiance fonctionnant à grande vitesse. Selon BleepingComputer, Firefox a poussé un blocage OneCRL le 17 octobre, les mises à jour Firefox 158.0.1 et ESR suivant le 20 octobre pour les utilisateurs dont les configurations avaient bloqué la mise à jour précédente ; Chrome a bloqué les six intermédiaires capables de TLS le 17 octobre également, et Apple a suivi le 19 octobre ; eMudhra a révoqué les huit certificats le 18 octobre. Mozilla a ensuite annoncé le retrait d'urgence de la confiance dans la racine parente emSign ECC Root CA - G3, Chrome s'engageant sur une voie similaire ; eMudhra estime qu'environ 30 000 certificats devront migrer, selon son propre commentaire dans le rapport de bug de Mozilla.

Deux mises en garde honnêtes vont dans des directions opposées. Rassurant : rien ne prouve que les clés faibles aient jamais été détournées, et eMudhra affirme qu'aucun certificat d'entité finale n'a été émis depuis les séries concernées. Moins rassurant : l'une des clés privées a été publiée sur GitHub par un chercheur, et les logiciels qui embarquent leur propre magasin de confiance ou sautent les vérifications de révocation (le suivi d'incident de Mozilla, tel que rapporté par BleepingComputer, cite le curl intégré de macOS comme exemple) peuvent continuer à faire confiance aux certificats jusqu'à leur mise à jour. Pour un lecteur, l'ensemble des actions tient en une ligne : mettez à jour votre navigateur et votre système d'exploitation. Les problèmes de certificats sont exactement la catégorie où un VPN ne change rien, même s'il vaut la peine de rappeler que des certificats forgés ou indûment approuvés importent surtout à un attaquant qui peut déjà intercepter votre trafic, ce qui est une des raisons pour lesquelles chiffrer votre connexion sur le Wi-Fi public (page en anglais) reste une hygiène raisonnable.

Pourquoi la publication PHP d'aujourd'hui comptait-elle autant ?

Mardi après-midi, le projet PHP a publié un avis inhabituel sur php.net : une publication de sécurité programmée pour le mercredi 21 octobre à 14h00 UTC, traitant deux vulnérabilités critiques, les détails complets devant être publiés avec la sortie. Préannoncer un correctif critique est un compromis délibéré : cela donne aux défenseurs une journée pour planifier des fenêtres de maintenance, au prix de signaler aux attaquants que quelque chose de précieux arrive. La publication est ensuite arrivée un peu en avance : les avis GitHub sont horodatés à 13h34 UTC, 15h34 à Paris, et l'annonce de PHP, intitulée « Vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant », désigne comme versions corrigées PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent CVE-2026-109618 et CVE-2026-109619, « deux vulnérabilités critiques pouvant permettre une exécution de code à distance non authentifiée », toutes deux notées CVSS v4.0 9,2.

Les deux failles s'énoncent simplement. CVE-2026-109618, « RCE via corruption OOM » : la gestion du manque de mémoire peut interrompre PHP alors que des données internes de requête ne sont que partiellement initialisées, et le nettoyage de la requête peut alors traiter ces données invalides comme valides. CVE-2026-109619, « RCE via état global périmé » : un état interne appartenant à une requête peut survivre après la libération de sa mémoire, et une requête ultérieure traitée par le même worker peut l'utiliser, un use after free. Qui est à risque, selon PHP : « toutes les installations PHP servant des requêtes web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed ». Le risque est le plus élevé pour mod_php, « avec un exploit démontré où une requête non authentifiée peut déclencher l'attaque avant l'exécution de tout code applicatif ». Un exploit démontré n'est pas la même chose qu'une exploitation dans la nature ; l'avis de PHP ne signale pas d'attaques dans la nature.

L'embargo avait fuité quand même. Des analyses de sociétés de sécurité, dont celle de SecureLayer7, suivaient les failles sous les références CVE-2026-109618 et CVE-2026-109619 et rapportaient qu'une preuve de concept baptisée « PHP2Shell » avait fait surface avant la publication ; le projet PHP ne l'a pas vérifiée, même si SecureLayer7 rapporte qu'au moins une société de sécurité affirme avoir reproduit l'une des failles. Les avis de PHP du 21 octobre ne signalent aucune exploitation dans la nature.

Reste tout le monde sur une branche ancienne. « PHP 8.1 et antérieurs ne reçoivent plus de mises à jour du projet PHP », note l'annonce, même si certaines distributions et certains fournisseurs LTS proposent des correctifs rétroportés. « Vu la gravité », l'équipe de sécurité de PHP a aussi publié des rétroportages minimaux au niveau du code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent depuis les sources ou n'ont pas de fournisseur LTS ; ce sont des patchs à appliquer, pas des versions prêtes à l'emploi. Le projet n'a publié aucun rétroportage pour PHP 7.3 et antérieurs, y compris PHP 5. Les distributions Linux et les fournisseurs LTS ont reçu les patchs à l'avance, et PHP 8.2 lui-même atteint sa fin de vie le 31 décembre 2026. L'avis de PHP liste des mesures provisoires pour ceux qui ne peuvent pas mettre à jour immédiatement, comme régler memory_limit à -1, abaisser post_max_size ou désactiver la progression d'envoi de session, mais précise qu'elles « réduisent l'exposition à certains chemins d'attaque mais ne rendent pas une installation sûre » ; selon les notes de publication, « mettre à jour est le seul choix sûr ».

L'échelle, voilà le sujet. Selon W3Techs, PHP fait tourner 69,3 % des sites web dont le langage côté serveur est connu, et parmi ces sites PHP, 27,0 % utilisent encore la version 7 et 7,7 % la version 5, des branches arrivées en fin de vie il y a des années. Les sites sous version 7 incluent PHP 7.4, qui dispose désormais au moins d'un rétroportage au niveau du code source ; les sites sous PHP 5, et sous PHP 7.0 à 7.3, ne reçoivent aucun rétroportage du projet. L'avis 2026-018 du CERT-EU avertissait que les vulnérabilités pourraient toucher toutes les versions de PHP depuis PHP 5 ; cet avertissement reste le sien, tandis que les avis GitHub ne listent comme affectées que les branches supportées, en dessous de 8.2.35, 8.3.36, 8.4.27 et 8.5.12, et n'énumèrent pas les versions en fin de vie. Pour les administrateurs système de la première section, c'est le travail de ce soir et le projet de migration du prochain trimestre, annoncés le même mardi que tout le reste.

Quoi d'autre a atterri sur les bureaux des défenseurs cette semaine ?

Lundi et mardi ont continué d'en rajouter. L'avis conjoint AA26-293A de la CISA et du FBI (20 octobre) détaille SafePay, une opération de rançongiciel qui a touché au moins 600 organisations depuis août 2024. Pour empêcher les victimes de se rétablir, dit l'avis, SafePay arrête le service Volume Shadow Copy et remet les stockages de sauvegarde en réseau en configuration d'usine, supprimant dans certains cas toutes les sauvegardes accessibles par le réseau. Le conseil central de l'avis est une vieille sagesse avec une urgence nouvelle : les sauvegardes doivent être hors ligne, immuables et réellement testées, parce que les copies joignables par le réseau sont précisément ce que ce groupe détruit.

Le catalogue des Known Exploited Vulnerabilities de la CISA a eu une semaine chargée lui aussi : quatre failles de Plex Media Server pouvant être chaînées ont été ajoutées le 20 octobre, ce qui compte parce que Plex est la rare entrée KEV qui se trouve dans les salons plutôt que dans les centres de données. Plus tôt dans la semaine sont arrivés BeyondTrust Remote Support et Fortinet (16 octobre), Atlassian Data Center (15 octobre), ainsi que Palo Alto PAN-OS, Cisco Secure Email Gateway et Ahsay (14 octobre). Chaque entrée s'accompagne de preuves d'exploitation dans la nature.

Deux éléments supplémentaires ont encadré la semaine. Une exclusivité Reuters du 19 octobre décrivait un pirate isolé qui a utilisé des agents IA autonomes pour tenter des intrusions sur plus de 1 200 sites et pénétrer les sites de plus de 100 entreprises, pour un coût d'environ 50 dollars par intrusion, selon un chercheur de NorForge ; Reuters n'a pas pu établir quelles données ont été dérobées. Quel que soit le bilan final, l'économie est le vrai sujet : si une intrusion coûte environ 50 dollars, les coupes budgétaires des données ISC2 paraissent encore plus difficiles à justifier. Et mardi, une panne de Google Cloud dans sa région de Londres a coïncidé avec des cartes Revolut refusées à travers l'Europe ; Revolut a confirmé la cause elle-même dans la soirée du 20 octobre, annonçant à 19h39 heure de Paris que le problème avait été corrigé et les services rétablis, en désignant une panne de Google Cloud comme cause, Google attribue sa panne à un événement électrique dans une zone de sa région de Londres, et rien ne la relie à PwnEscape. Nous l'avons couverte séparément dans notre article sur la panne Revolut.

À quoi ressemble la semaine entière, mise côte à côte ?

Que devriez-vous réellement faire cette semaine ?

Pour la plupart des lecteurs, la réponse honnête est courte. Mettez à jour votre navigateur et votre système d'exploitation, ce qui règle discrètement l'histoire des certificats. Si vous faites tourner Plex Media Server chez vous, mettez-le à jour aujourd'hui ; ces failles sont exploitées, pas simplement théorisées. Et attendez-vous à du phishing qui emprunte les gros titres de la semaine, du genre « votre compte a été exposé dans la brèche PHP » ; un filtre DNS qui bloque les domaines de phishing connus avant leur chargement, comme la Threat Protection de Le VPN, aide dans ce cas, et si un courriel prétend que votre adresse e-mail a été prise dans une fuite, vérifiez-la vous-même contre les fuites connues plutôt que de cliquer sur le lien. Notre hub de sécurité en ligne couvre le reste des bases.

Si vous possédez un site web : découvrez ce soir quelle branche PHP vous utilisez. En 8.2 à 8.5, la mise à jour est sortie : appliquez 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 maintenant, ou demandez à votre hébergeur si elle est appliquée, puisque les distributions Linux et les fournisseurs LTS ont reçu les patchs à l'avance. En 7.4, 8.0 ou 8.1, les options sont les rétroportages minimaux au niveau du code source de l'équipe de sécurité de PHP ou le correctif rétroporté d'un fournisseur. En 7.3 ou antérieur, y compris PHP 5, considérez cela comme le déclencheur de la migration que vous repoussiez, et dans l'intervalle, envisagez la suggestion du CERT-EU d'isoler tout ce qui est exposé à Internet et ne peut pas être patché. Si votre site vit sur un VPS, il est légitime de poser deux questions à votre fournisseur : les noyaux des hôtes ont-ils été patchés contre CVE-2026-99999, et quand est la fenêtre de redémarrage. Et vérifiez que vos sauvegardes existent quelque part où un rançongiciel ne peut pas les atteindre : SafePay réinitialise ou supprime les sauvegardes en réseau précisément parce que les victimes comptent dessus.

Si vous dirigez des personnes qui font ce travail, les chiffres d'enquête en haut de cet article ne sont pas une curiosité RH ; ce sont un indicateur de risque. Le Voice of the CISO 2026 de Proofpoint a constaté que 77 % des RSSI disent que des attentes excessives pèsent sur eux, et la recherche IANS/Artico sur l'engagement des conseils d'administration a constaté que seuls 29 % des administrateurs jugent très efficaces les points cyber qu'ils reçoivent. Une équipe qui a passé cette semaine à patcher des hôtes, faire tourner des certificats et lire des fuites d'embargo à minuit recommencera le mois prochain. Qu'elle le fasse bien, ou en mettant à jour son CV, relève en partie d'une ligne budgétaire.

Un dernier paragraphe honnête. Un VPN n'aurait empêché aucun des événements de cette liste. Il ne corrige pas les serveurs, ne répare pas les bugs du noyau ou de PHP sur les sites que vous visitez, n'empêche pas les pannes cloud et ne remplace pas les mises à jour du navigateur qui ont bloqué les mauvais certificats. Ce qu'il fait est plus étroit et toujours utile : il chiffre le trafic entre votre appareil et le serveur VPN, de sorte que quelqu'un sur le même Wi-Fi de café ne puisse pas intercepter ce que vous envoyez. Savoir précisément ce que fait un outil, et le dire, semblait être la bonne façon de terminer une semaine qui a carburé à la peur du non-confirmé.

Les correctifs sont arrivés cet après-midi, heure de Paris. Quelque part, un administrateur fatigué a un terminal ouvert et une fenêtre de maintenance réservée, et d'ici jeudi, personne en dehors de l'équipe ne se souviendra que c'est arrivé. Voilà à quoi ressemble la sécurité quand elle fonctionne : à rien, visiblement, du tout.