4 !

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.

Des clés privées associées à huit certificats intermédiaires compromises

« 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.

Des clés « intrinsèquement faibles »

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.

Les certificats rapidement bloqués pour la navigation web

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.

Des services à mettre à jour, une résolution plus compliquée pour le matériel

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.

eMudhra assure qu’aucun certificat ne s’appuyait sur ces clés et qu’une seule était en production

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 ».

Mise à jour, 21h30 : Orange a annoncé le rétablissement de ses services dans un communiqué adressé par mail peu après 21 heures.

L’opérateur ne s’étend pas en détail, pour l’instant, sur les causes de cette longue coupure. Il l’attribue simplement « à une défaillance d’un équipement au niveau de [son] cœur de réseau mobile ».

« Les appels, les SMS et les usages mobiles sont de nouveau opérationnels pour les clients particuliers comme pour les entreprises. Les équipes techniques d’Orange sont restées pleinement mobilisées pendant toute la durée de l’incident et poursuivent la surveillance du réseau afin de s’assurer de la stabilité et de la qualité des services dans les prochaines heures. », ajoute-t-il.

On attend maintenant de voir si l’incident donnera lieu à une compensation financière pour les clients victimes, et à la publication d’un post mortem technique détaillé.

---

Mise à jour, 19h10 : la panne se prolonge pour une partie des abonnés Orange. Vers 18h30, plusieurs de nos contacts signalent n’avoir toujours pas récupéré la connexion mobile sur leur smartphone, sept heures environ après le début de l’incident. Le volume des signalements sur Downdetector a baissé, mais le site répertorie tout de même plusieurs centaines d’alertes par heure.

L’opérateur ne s’est pour l’instant pas exprimé sur les causes techniques de cet incident, même s’il a fait parvenir un communiqué de presse vers 19 heures à la rédaction :

« Les équipes techniques d’Orange sont pleinement mobilisées pour rétablir les services dans les meilleurs délais. Dans l’attente du rétablissement complet, Orange rappelle à ses clients qu’ils peuvent conserver la plupart de leurs usages mobiles (accès au site internet mais aussi communication au travers de services de messagerie et de visioconférences) en se connectant à un réseau Wi-Fi disponible et sécurisé. »

Certains indices dessinent une hypothèse relative à la migration d’une partie du parc d’abonnés Orange (ou des clients d’opérateurs virtuels empruntant son réseau) vers le cœur de réseau mobile nouvelle génération qui accompagne notamment le déploiement de la 5G SA.

À ce stade, impossible toutefois d’être catégorique. Quelques utilisateurs affirment avoir retrouvé l’accès à leur connexion mobile en forçant l’utilisation de la 3G sur leur appareil. Orange précise par ailleurs que les appels d’urgence ne sont pas concernés par la panne.

D’autres s’interrogent sur l’éventuel lien entre cette panne et la coupure du réseau 2G historique d’Orange, dont la dernière vague est survenue mardi 20 octobre sur une large portion du territoire métropolitain. L’extinction de la 2G aurait-elle supprimé un canal de supervision ou de reprise à distance ? Hormis la proximité temporelle, rien ne permet d’accréditer sérieusement cette thèse.

• La 2G s’éteint dans trois mois… mais il y a encore 1,7 million de cartes SIM actives

---

Publication initiale, 12h30

Depuis 11h30 environ mercredi matin, les signalements relatifs à une indisponibilité du réseau mobile Orange se multiplient, avec des témoignages qui laissent augurer un problème sensible à l’échelle nationale.

Le site Downdetector relève ainsi quelque 8 000 alertes réparties entre Orange et sa marque Sosh entre 11h30 et midi.

L’opérateur a confirmé à 12h12 qu’un incident était en cours au niveau de ses infrastructures.

« Bonjour, vous pouvez rencontrer actuellement des perturbations sur le réseau mobile Orange. Nos équipes sont pleinement mobilisées pour rétablir le réseau dans les meilleurs délais. Veuillez nous excuser pour la gêne occasionnée. »

Aucun détail technique n’a cependant été donné à ce stade. Nous reviendrons sur le sujet dès que de plus amples informations seront disponibles.

L’opérateur avait déjà été victime d’une panne d’envergure nationale le 29 juin dernier.

Toujours des noms simples à prononcer

Mistral a lancé récemment deux modèles spécialisés, Voxtral 3 pour transcription et la synthèse vocale et Timestral pour les « séries temporelles ». Ce dernier doit permettre des prévisions sans réentrainement.

Mistral avait lancé son premier modèle Voxtral en juillet 2025. Il s’agissait alors de son premier modèle audio, que Mistral mettait en avant comme plus performant et moins cher que les solutions concurrentes. Plusieurs tailles étaient proposées, selon la durée des contenus audio que l’on souhaitait traiter.

Ce LLM spécialisé a beaucoup évolué, puisque la version 3 est maintenant disponible. La communication de Mistral braque largement les projecteurs sur les agents. Selon l’entreprise française, un agent vocal fiable doit ainsi maitriser quatre capacités : écouter avec précision, raisonner en profondeur sur ce que les utilisateurs veulent dans un contexte donné, parler naturellement et agir en plusieurs étapes.

Un SDK d’agents locaux

Voxtral 3 est la réponse de Mistral à ces quatre objectifs, dont un fonctionnement fiable et en temps réel « reste un défi ». Voxtral 3, comme le premier, désigne une famille de modèles spécialisés dans la reconnaissance et la synthèse vocales. Cette fois, elle est accompagnée d’un SDK (kit de développement logiciel) pour utiliser des agents locaux. Le SDK (bâti sur LiveKit) réunit dans un même pipeline de traitement l’écoute, la réflexion, l’appel d’outils et la parole.

La famille compte quatre modèles :

• Small Transcribe 3 : transcription groupée de meilleure précision, 50 langues, à 0,004 dollar la minute
• Mini Transcribe 3 : 4 milliards de paramètres, 0,0035 dollar la minute
• Mini Transcribe Realtime 3 : transcription en direct, latence revendiquée à moins de 500 ms, 0,008 dollar la minute
• Voxtral Speech 3 (ou Mini TTS 3.0) : synthèse vocale, plus de 35 langues et 50 dialectes, 13 dollars le million de caractères

Mistral vante l’émotion dans la voix pour « sonner naturellement » (prosodie, rythme, débit, accentuation et transitions), les performances en diarisation (reconnaître qui parle) et la prise en charge des biais contextuels. Pour ce dernier point, Mistral précise que l’on peut ainsi fournir des termes clés et du texte libre pour « orienter la transcription et améliorer le rappel des termes techniques ». L’entreprise ajoute le support de la prédiction de fin de tour, les modèles étant capables de prédire quand une personne a fini de parler, en se basant sur des informations acoustiques et sémantiques.

Selon l’annonce, les performances de ces modèles sont à « l’état de l’art », dépassant de nombreuses références du secteur, dont Whisper d’OpenAI. L’agent complet, lui, est facturé 0,04 dollar la minute avec Small et 0,08 dollar avec un autre modèle de raisonnement. L’accès se fait via l’API de Mistral ou depuis l’infrastructure sur site.

Signalons que les quatre modèles sont en préversion publique et que certaines informations manquent. Par exemple, la taille de Small n’est pas donnée. En outre, aucun poids ouvert n’a encore été annoncé. En revanche, les performances revendiquées par Mistral semblent confirmées par Artificial Analysis.

Timestral : c’est quoi des « séries temporelles » ?

Le 15 octobre, Mistral avait également lancé un autre modèle, Timestral, premier représentant d’une nouvelle famille de LLM. Il est spécialisé dans les séries temporelles, c’est-à-dire des séries de mesures datées (capteurs, consommation, flux financiers…), afin d’établir des prévisions.

Timestral est fourni en quatre tailles : 5, 28, 123 et 209 millions de paramètres. Le modèle peut prévoir les séries sans réentraînement sur des données spécifiques, produire des prévisions avec une fourchette d’incertitude (21 quantiles) et accepter jusqu’à 32 768 pas d’historique. Selon Mistral, il peut traiter plusieurs séries liées à la fois ainsi que des facteurs connus à l’avance (calendrier de production, météo, etc.).

Timestral fonctionne également sans carte graphique. Mistral annonce à ce sujet un temps allant de 10 à 140 ms pour prévoir une journée, en fonction de la taille du modèle utilisé, sur un « CPU de serveur standard avec 8 threads » et sur la base de trois semaines d’historique au pas de 15 min. Comme toujours avec la taille des modèles, plus elle est importante, plus la précision augmente et plus le temps de calcul s’allonge.

Le code du modèle est sous licence Apache 2.0. Cependant, comme relevé par Pix Geeks, les poids sont sous une licence MIT modifiée « qui exclut les entreprises dont le chiffre d’affaires mensuel consolidé dépasse 20 millions de dollars. Celles-là doivent demander une licence commerciale à Mistral ou passer par ses services hébergés ». Sous ce seuil, l’utilisation de Timestral est gratuite.

Chauffe Marcel

Que ce soit par les collectivités ou les opérateurs, la récupération de chaleur est fréquemment citée comme argument valorisant la présence de ces bâtiments au sein d’un territoire. En pratique, le chercheur Loup Cellard constate la complexité des négociations relatives à la mise en place de la récupération et de la réutilisation de la chaleur émise.

Un ordinateur, ça chauffe. Des dizaines d’ordinateurs, ou plutôt de serveurs, stockés dans un seul bâtiment pour héberger des services de cloud ou des modèles d’IA, ça chauffe d’autant plus. C’est la raison pour laquelle, depuis des années, les acteurs de l’industrie des centres de données proposent aux collectivités de récupérer la chaleur fatale (énergie émise par l’activité, sans en être la finalité, et souvent sans être réutilisée) qu’ils émettent, entre autres arguments pour faciliter leur implantation.

En France, ce réusage est même passé dans la loi. L’article 26 de la directive européenne sur l’efficacité énergétique, adoptée en 2023 et transposée en France par un décret de décembre 2025, « oblige les centres de données les plus énergivores à valoriser la chaleur qu’ils produisent ». Pourtant, d’après les données de la Commission européenne, 0,1 % de la chaleur fatale émise par les centres de données implantés dans le pays est effectivement récupérée. C’est nettement moins que la moyenne européenne, quand bien même celle-ci plafonne de 2 à 9 % de chaleur fatale réutilisée.

Dans un récent rapport de l’Observatoire sur l’impact environnemental de l’IA de l’École normale supérieure, titré « La chaleur des data centers, un déchet qui voulait devenir une ressource pour les territoires », le chercheur Loup Cellard se penche sur les raisons de ces difficultés. Côté freins, il relève non seulement les problématiques techniques et géographiques facilement compréhensibles – certains centres de données se trouvent trop loin d’une clientèle susceptible d’être intéressée par la chaleur émise, par exemple –, mais aussi des problèmes de coordination et de négociation entre acteurs impliqués.

• Carte mondiale datacenters et ressources associées

Votre data center, vous le prendrez avec ou sans gestion de l’énergie et de la chaleur ?

L’industrie des centres de données n’est pas connue pour sa transparence – fin septembre, un collectif de journalistes regrettait même, enquête à l’appui, l’absence de volonté des États membres et de l’Union européenne sur le sujet. « C’est ici que l’une des missions sociales de la recherche académique se dessine », écrit Loup Cellard, avant de détailler la trentaine d’acteurs rencontrés pour des entretiens semi-directifs.

Pour dessiner une image précise des complexités relatives à l’émission de chaleur fatale des centres de données, le chercheur a rencontré des opérateurs ou ex-opérateurs de centres de données de colocation classiques ou alternatifs, des gestionnaires de réseaux de chaleur urbains, des agents publics chargés de la gestion de centres de données, des énergéticiens, des architectes et divers autres acteurs impliqués dans la construction et l’intégration des centres de données dans le tissu urbain ou rural.

• Datacenters : c’est quoi un campus, les Tiers, un hyperscaleur, la colocation, on premises…

Parmi les principaux constats que ces rencontres lui permettent d’établir : l’argumentaire de la réutilisation de la chaleur reste opérant dans la mesure où il permet aux data centers de se présenter « comme de bons acteurs énergétiques, à la fois performants dans leur optimisation des systèmes et volontaires à valoriser leur chaleur ». Depuis ce point de vue, ils promettent de « valoriser la chaleur comme un déchet dans une économie circulaire », par ailleurs intensifiée ces dernières années par le déploiement de l’IA générative.

Pour autant, la mise en place effective de ces circuits reste complexe. Ces deux axes placent les opérateurs de centres de données face à un paradoxe. Ils peuvent, d’un côté, maintenir une stricte division entre leurs métiers et ceux des énergéticiens. Ils risquent cependant d’être rangés dans la catégorie des gros consommateurs industriels d’énergie, avec tous les débats que cela suscite.

Autre possibilité : s’engager réellement dans la réutilisation de la chaleur émise, ou dans la gestion et le stockage de l’électricité. Dans ce cas, en revanche, c’est le métier lui-même qui mute, pour tenter de « faire coïncider leurs activités avec les valeurs et objectifs d’une économie circulaire ».

À qui revient la charge d’assurer la récupération de chaleur ?

Au sein des territoires, l’intérêt pour la récupération de la chaleur émise par les centres de données se justifie de plusieurs façons. Un argument quelquefois utilisé est celui de l’autonomie énergétique : en la matière, les data centers permettraient de « devenir moins dépendants des chaînes d’approvisionnement fossiles et lointaines (pétrole, gaz russes ou américains) ». 

Un autre consiste à s’assurer que le bâtiment s’intègre au territoire « de manière écologiquement positive », alors que le scénario de maintien des températures mondiales sous le seuil de 1,5 °C de réchauffement par rapport au niveau pré-industriel vient d’être dépassé. Dans un tel cas, la chaleur devient « une forme de compensation pour ce que l’opérateur va retirer au territoire (emprise au sol, grande réservation d’électricité, risque de pollution associé) », écrit Loup Cellard.

Mais le problème qui émerge rapidement est celui de la responsabilité et de la coordination des acteurs, y compris au gré des variations saisonnières. Directeur général des services de Generia, le syndicat réseau de chaleur de La Défense, Gérald Chirouze témoigne par exemple du cas d’un centre de données branché au sous-réseau de Courbevoie « Seinergie », qu’il approvisionne à hauteur de 20 MW. Or, pour approvisionner les 14 000 logements raccordés, le besoin courant est de 45 MW, mais tombe à 9 MW l’été. Il faut, dans ces cas-là, trouver un autre usage à la chaleur.

Plus généralement, des freins techniques sont mis en avant, à commencer par celui selon lequel l’essentiel des centres implantés en France émettent une chaleur trop basse, entre 20 et 25 °C, pour être raccordés directement aux réseaux de chaleur. En général, ces derniers nécessitent en effet des chaleurs de plus de 60 °C. Et même si la chaleur est destinée à de la production de culture maraîchère, l’eau doit être remontée à 55 °C pour chauffer correctement. Dans la plupart des cas, il faut donc ajouter une pompe à chaleur :

À ceci viennent s’ajouter des contraintes géographiques – à Nozay ou aux Ulis, en Essonne, les projets de Data4 et de Digital Realty ne trouvent pas de clientèle pour leur chaleur, par exemple –, ou spatiales. Si les bâtiments sont installés à plus de 3 km de leur destination, « la chaleur descend trop pour pouvoir être utilisée sans être maintenue ». Et puis vient la question de la négociation économique : difficile de savoir qui, « entre collectivités, gestionnaires de réseaux de chaleur et opérateurs de data centers », doit payer pour l’installation de pompes à chaleur et les travaux de raccordement. En la matière, les collectivités sollicitées indiquent ne pas connaître les capacités financières des opérateurs, ce qui complique la négociation de la répartition des coûts d’investissement.

Juridiquement, les data centers sont contraints depuis le 29 décembre 2025 à organiser la récupération d’au moins 20 % de leur chaleur fatale, « sauf si l’opérateur est capable de démontrer auprès des collectivités locales compétentes que le projet n’est pas faisable économiquement ou techniquement ». En l’espèce, le rapport suggère que les opérateurs n’auront pas de mal à démontrer la complexité de cette entreprise, sauf si l’administration se fait « particulièrement intransigeante en la matière ».

En définitive, son auteur souligne les besoins « de concertation et de planification énergétique » remontés par les spécialistes interrogés sur le terrain. À l’heure actuelle, « lorsque les contraintes techniques d’injection de chaleur sont maîtrisées », si la chaleur des data centers reste inutilisée, c’est le plus souvent par « manque d’anticipation et de connaissances mutuelles entre opérateurs d’infrastructures et réseaux de chaleur ».

En guise d’exemple réussi, le rapport se penche sur le cas d’un data center d’Equinix géré par une filiale d’Engie Solutions et alimentant logements, bureaux et centre aquatique de Saint-Denis. « Comme pour d’autres projets de récupération de chaleur (géothermie, usines de déchets, etc), la valorisation de la chaleur des data centers est grandement facilitée lorsqu’elle rencontre les ambitions d’un territoire en termes de décarbonation du mix énergétique. » Pour cela, souligne-t-il encore, il faut aussi que l’industrie concernée s’engage réellement.

• Datacenters : de l’Europe aux États membres, personne n’impose la transparence

À vos marques ! Prêts ?

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. »

Plusieurs sites baissent le rideau préventivement

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.

Des attaques déjà recensées, Node.js lance aussi une alerte

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.

Des failles exploitables à distance

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.