Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Il y a le bon CVE et le mauvais CVE

La publication en 48 heures de 432 bulletins CVE pour le noyau Linux a provoqué des interrogations sur la meilleure manière d’intégrer un tel flot de corrections dans les environnements de production. La situation est plus complexe qu’il n’y paraît.

Entre les 20 et 21 juillet, un lot conséquent de 432 CVE a été publié pour le noyau Linux. Cela ne signifie pas que 432 failles ont été corrigées, car le fonctionnement des CVE est différent pour le noyau. En revanche, ils correspondent quand même à des corrections portées dans la branche principale par les mainteneurs du noyau. Se pose alors la question de leur répercussion concrète.

D’abord, qu’est-ce qu’un CVE ? C’est un identifiant unique (Common Vulnerabilities and Exposures) attribué à une faille de sécurité informatique connue publiquement. Une telle vulnérabilité se définit par une faiblesse de la logique d’un logiciel, permettant alors à un attaquant de violer la politique de sécurité et d’effectuer des actions auxquelles il n’a normalement pas droit. Dans la plupart des cas, les CVE sont publiés avant les correctifs associés, car ils servent souvent de base pour les bulletins de sécurité. Le CVE s’accompagne généralement d’un score CVSS (Common Vulnerability Scoring System), censé représenter le niveau de dangerosité de la faille, et de détails contextuels (vecteur d’attaque à distance, niveau de privilèges requis, etc.).

• CVSS 4.0 : dur, dur, d’être un expert !

Il y a CVE et CVE

Les CVE sont attribués par les CNA (CVE Numbering Authorities). Or, depuis février 2024, le projet Linux est devenu sa propre autorité de numérotation, avec des règles spécifiques pour répondre à l’échelle de son immense base de code.

Pour comprendre la situation actuelle, il faut retenir que ces règles sont inversées par rapport au reste de l’industrie. Dans un cas classique, la découverte d’une faille entraine l’attribution d’un CVE, l’alerte puis le développement du patch. Que les détails soient parfois publiés plus tard n’y change rien, le CVE est attribué d’abord. Au sein du projet Linux, c’est le contraire : la découverte d’une faiblesse dans le code entraine le développement d’un patch puis la fusion de celui-ci dans les branches stables du noyau, et seulement après l’apparition d’un CVE. Ce qui signifie qu’au sein du noyau Linux, les failles non corrigées n’ont pas de CVE.

Autre précision importante : l’équipe du noyau attribue systématiquement un CVE à tout correctif de bug susceptible d’impacter la stabilité ou l’accès mémoire, sans chercher à qualifier si le bug est facilement exploitable ou non. C’est ce qu’expliquait sur son blog Greg Kroah-Hartman, mainteneur principal des branches stables du noyau, en février dernier. De même, aucun score CVSS n’est produit, et pour cause : les développeurs du noyau ne connaissent pas l’usage fait de Linux, donc dans quel type d’environnement le code sera exécuté.

En revanche, là où un CVE traditionnel décrit un comportement de haut niveau, un CVE Linux correspond directement à un identifiant de commit Git. Ce suivi automatisé explique pourquoi l’utilisation massive de fuzzers et d’outils d’analyse statique génère des pics soudains de plusieurs centaines de CVE.

Mais alors, où est le problème ?

Si la publication de 432 CVE est en soi inédite, ils correspondent donc à des bugs déjà corrigés. Pourtant Jan Schaumann, architecte en chef de la sécurité de l’information chez Akamai Technologies, s’en est plaint sur la liste de diffusion OSS-SEC. Il y exprime son inquiétude devant un tel volume, demandant comment les entreprises, et de manière générale les environnements de production, peuvent suivre un tel rythme.

Mais en quoi est-ce un problème ? Si les failles sont déjà corrigées, ne suffit-il pas d’attendre sagement la prochaine révision du noyau ? Ce n’est pas si simple.

Plusieurs éléments doivent être considérés. D’un côté, les corrections intégrées aux branches stables signifient que toutes les versions actuellement supportées du noyau Linux vont les répercuter. En théorie, il suffirait d’installer la version suivante dans la branche utilisée, par exemple la 7.2 si l’on utilise une distribution évoluant avec les versions les plus récentes. De l’autre, les environnements de production utilisent souvent des versions modifiées, voire d’anciennes versions dans lesquelles les équipes « backportent » (rétroportent) les modifications qui les intéressent.

C’est là que survient le problème dont se plaint Jan Schaumann : quand 432 CVE sont publiés en 24 heures, comment savoir ce qui est important et doit être rétroporté ? Dans un courrier envoyé à The Register, il évoque la possibilité de faire travailler des LLM pour gérer automatiquement le flux. « Des mises à jour automatisées, régulières et fréquentes qui intègrent tous les changements dans un délai donné me semblent la seule approche raisonnable, mais cela est très difficile pour de nombreuses grandes organisations », explique-t-il ainsi.

Le dernier noyau disponible, toujours

Sur la liste de diffusion OSS-SEC, la discussion présente des réponses intéressantes, notamment celle de Greg Kroah-Hartman en personne. Bien qu’il ne réagisse pas directement au message initial, les solutions envisagées par d’autres sont passées en revue, et il donne nettement sa préférence : toujours utiliser le dernier noyau stable disponible sur la branche souhaitée et vérifier régulièrement l’ensemble des systèmes gérés.

Kroah-Hartman reconnait que ce n’est pas toujours simple au sein des entreprises, mais que des produits payants permettent de gérer efficacement ce processus. Si payer un tel produit n’est pas possible, il recommande d’installer des distributions comme Debian ou Yocto, car « leurs pratiques de sécurité sont extraordinaires ». Les autres solutions représentent plus de travail ou une sécurité moindre. Vérifier un par un les CVE pour ne considérer que ceux importants dans l’infrastructure ? On peut le faire de manière automatisée pour vérifier ce qui ressort à l’intersection des fichiers visés par les CVE et des fichiers réellement utilisés dans l’environnement géré. Mais on en revient à la proposition de Jan Schaumann, et toutes les organisations ne peuvent pas se permettre un tel pipeline de gestion.

En d’autres termes, la meilleure solution reste la répercussion des nouveaux noyaux quand ils deviennent disponibles, mais l’explosion du nombre de CVE – très probablement portée par l’utilisation croissante des LLM – rend la lecture plus complexe. Pour Greg Kroah-Hartman cependant, il n’y a pas vraiment de problème : les 432 CVE étaient en préparation depuis des semaines, personne ne devrait être surpris.

Il existe de nombreuses méthodes de sécurité pour se connecter à son compte Google, mais la loi de Murphy étant universelle et intangible, il peut arriver que tout se passe mal et qu’aucune ne fonctionne. Le moteur de recherche en a donc ajouté une nouvelle qui ne devrait plus se perdre au fin fond d’un gestionnaire de mots de passe : le visage.

Google est en train de déployer une fonction de selfie vidéo pour récupérer son compte. Il faudra au préalable enregistrer un selfie vidéo, en suivant les indications de mouvements de tête de l’application. En cas de problème de connexion au compte, l’app peut proposer de réaliser un selfie, qui sera comparé à celui déjà enregistré. Une fois l’identité vérifiée, l’accès sera rétabli.

Évidemment, cette nouvelle méthode pose quelques questions de confidentialité, ce d’autant que le selfie vidéo original est stocké sur les serveurs de Google. L’entreprise se veut rassurante : les données sont enregistrées « de manière sécurisée » (elles sont chiffrées au repos) et avec le consentement de l’utilisateur. La vidéo ne sert que pour l’aide à la connexion, et il est possible de la supprimer à tout moment depuis le compte Google.

Autre inquiétude très concrète : les tentatives d’usurpation d’identité. Des malandrins pourraient en effet être tentés d’utiliser de fausses photos ou vidéos pour se connecter subrepticement dans le compte Google d’une victime. On n’ose imaginer les dégâts possibles, puisque ces comptes contiennent une bonne partie de la vie des utilisateurs…

Plusieurs niveaux de sécurité sont appliqués pour prévenir ces tentatives. « Nous comparons votre vidéo à celle que vous avez enregistrée et vous demandons d’effectuer quelques mouvements simples afin de vérifier qu’il s’agit bien d’une captation en direct », explique Google. Des « mesures de sécurité habituelles » sont également mises en œuvre pour détecter et bloquer les connexions suspectes.

Les plus suspicieux se contenteront des méthodes de connexion existantes, que ce soit une passkey ou un système de validation à deux étapes, comme le code d’une app d’authentification, une clé de sécurité physique ou une invite Google sur un téléphone déjà connecté. Il y a aussi le code reçu par SMS, mais cette méthode n’est pas spécialement sécurisée.

• Mots de passe, double authentification : grrrrr… il est temps d’agir !

Il existe de nombreuses méthodes de sécurité pour se connecter à son compte Google, mais la loi de Murphy étant universelle et intangible, il peut arriver que tout se passe mal et qu’aucune ne fonctionne. Le moteur de recherche en a donc ajouté une nouvelle qui ne devrait plus se perdre au fin fond d’un gestionnaire de mots de passe : le visage.

Google est en train de déployer une fonction de selfie vidéo pour récupérer son compte. Il faudra au préalable enregistrer un selfie vidéo, en suivant les indications de mouvements de tête de l’application. En cas de problème de connexion au compte, l’app peut proposer de réaliser un selfie, qui sera comparé à celui déjà enregistré. Une fois l’identité vérifiée, l’accès sera rétabli.

Évidemment, cette nouvelle méthode pose quelques questions de confidentialité, ce d’autant que le selfie vidéo original est stocké sur les serveurs de Google. L’entreprise se veut rassurante : les données sont enregistrées « de manière sécurisée » (elles sont chiffrées au repos) et avec le consentement de l’utilisateur. La vidéo ne sert que pour l’aide à la connexion, et il est possible de la supprimer à tout moment depuis le compte Google.

Autre inquiétude très concrète : les tentatives d’usurpation d’identité. Des malandrins pourraient en effet être tentés d’utiliser de fausses photos ou vidéos pour se connecter subrepticement dans le compte Google d’une victime. On n’ose imaginer les dégâts possibles, puisque ces comptes contiennent une bonne partie de la vie des utilisateurs…

Plusieurs niveaux de sécurité sont appliqués pour prévenir ces tentatives. « Nous comparons votre vidéo à celle que vous avez enregistrée et vous demandons d’effectuer quelques mouvements simples afin de vérifier qu’il s’agit bien d’une captation en direct », explique Google. Des « mesures de sécurité habituelles » sont également mises en œuvre pour détecter et bloquer les connexions suspectes.

Les plus suspicieux se contenteront des méthodes de connexion existantes, que ce soit une passkey ou un système de validation à deux étapes, comme le code d’une app d’authentification, une clé de sécurité physique ou une invite Google sur un téléphone déjà connecté. Il y a aussi le code reçu par SMS, mais cette méthode n’est pas spécialement sécurisée.

• Mots de passe, double authentification : grrrrr… il est temps d’agir !

Depuis le durcissement, le 20 juillet, des contrôles de sécurité dans le métro de Shenzhen, des files d’attente longues de plusieurs centaines de mètres sont apparues devant une dizaine de grandes stations. De quoi provoquer des critiques contre le discours officiel du “tout pour le peuple” prôné par les autorités, et même des appels à supprimer ces contrôles dans l’ensemble des métros du pays.

© PHOTO ZHANG KAIYV

Une nouvelle vulnérabilité critique touche le noyau Linux, cette fois via le système de fichiers XFS. Elle permet à n'importe quel utilisateur local, sans le moindre privilège, de prendre le contrôle total de la machine, sans laisser de trace.

Le 17 juillet, WordPress corrigeait en urgence deux failles au sein même de sa base logicielle. Depuis, de nombreux chercheurs en sécurité alertent sur une exploitation massive avec, parfois, un solide coup de main de l'IA.

Les alertes envoyées par les chercheurs en sécurité devraient suffire pour que les entreprises fassent le nécessaire et bouchent les failles rapidement. Mais parfois, il faut aussi secouer le cocotier pour qu’elles s’exécutent. C’est le cas d’Apple, qui a finalement corrigé une vulnérabilité dans son service « Masquer mon adresse e-mail » plus d’un an après sa découverte. La médiatisation de cette faille a forcé la main du constructeur.

Début juillet, on découvrait l’existence d’une vulnérabilité dans « Masquer mon adresse e-mail » (Hide My Email), un service offert aux abonnés iCloud+ d’Apple. La fonction crée automatiquement une fausse adresse durant l’inscription sur un site ou une application, afin de ne pas révéler sa vraie adresse. Cette faille permettait de retrouver l’adresse e-mail originale.

Le chercheur en sécurité Tyler Murphy d’EasyOptOut a prévenu Apple de sa découverte en juin 2025. En mars 2026, l’entreprise a affirmé que le problème avait été résolu… sauf que ce n’était pas le cas : la faille était toujours exploitable. Alertée de nouveau, Apple a indiqué en mai qu’un correctif avait été mis au point et serait appliqué dans les prochaines semaines, avant de se murer dans le silence.

• Une faille dans la fonction Hide My Email d’Apple peut révéler l’adresse principale

Tyler Murphy a alors contacté 404media pour médiatiser l’affaire, sans rien révéler sur la nature précise du problème afin de ne pas donner des idées à des malandrins. L’affaire a pris suffisamment d’ampleur pour qu’Apple se décide finalement à appliquer un correctif. Maintenant que la faille appartient au passé, le site explique qu’il suffisait d’envoyer un message à un utilisateur ciblé de « Masquer mon adresse e-mail » et que celui-ci soit rejeté comme spam pour pouvoir exploiter la faille.

« Nous ne pensons toutefois pas que tout risque soit désormais écarté », préviennent Tyler Murphy et Ben Weiner, le cofondateur de la société EasyOptOut. « Des e-mails non malveillants pouvaient être rejetés et révéler votre adresse masquée. Comme les journaux de transfert des messages sont souvent conservés, nous estimons que toute adresse masquée associée à une adresse créée avec “Masquer mon adresse e-mail” avant le 7 juillet 2026 a pu être exposée et pourrait encore figurer dans des journaux détenus par des tiers », précisent-ils.

Apple n’est donc peut-être pas encore au bout de ses peines. À cela s’ajoute une plainte (PDF) déposée en Californie le 17 juillet, qui accuse l’entreprise d’avoir trompé ses clients sur le niveau de confidentialité de la fonction « Masquer mon adresse e-mail », tout en la leur faisant payer.

Mise à jour — Un bug n’arrive jamais seul. Le développeur Jeff Johnson et MacGeneration ont mis la main sur une autre vulnérabilité qui touche directement le logiciel Mail d’Apple. Cette vulnérabilité permet à un plaisantin de récupérer l’adresse liée au compte Apple d’une personne qui ne souhaite pas la partager.

Le piège est très simple. Il suffit d’envoyer un courriel à l’adresse connue de la victime en ajoutant un en-tête spécifique qui active le bug. Le message affiche un bandeau « Ce message vous a été transféré via « Masquer mon adresse e-mail » », qui doit mettre la puce à l’oreille car il n’apparait habituellement pas.

Si l’utilisateur répond tout de même à l’e-mail malveillant depuis l’app Mail, son adresse « À: » sera celle du compte Apple… pas l’adresse d’origine à laquelle le courriel avait été envoyé. C’est embêtant, car on peut ne pas vouloir divulguer l’adresse de son compte Apple ou alors uniquement à des proches. Apple a été prévenue de ce nouveau bug.

Les alertes envoyées par les chercheurs en sécurité devraient suffire pour que les entreprises fassent le nécessaire et bouchent les failles rapidement. Mais parfois, il faut aussi secouer le cocotier pour qu’elles s’exécutent. C’est le cas d’Apple, qui a finalement corrigé une vulnérabilité dans son service « Masquer mon adresse e-mail » plus d’un an après sa découverte. La médiatisation de cette faille a forcé la main du constructeur.

Début juillet, on découvrait l’existence d’une vulnérabilité dans « Masquer mon adresse e-mail » (Hide My Email), un service offert aux abonnés iCloud+ d’Apple. La fonction crée automatiquement une fausse adresse durant l’inscription sur un site ou une application, afin de ne pas révéler sa vraie adresse. Cette faille permettait de retrouver l’adresse e-mail originale.

Le chercheur en sécurité Tyler Murphy d’EasyOptOut a prévenu Apple de sa découverte en juin 2025. En mars 2026, l’entreprise a affirmé que le problème avait été résolu… sauf que ce n’était pas le cas : la faille était toujours exploitable. Alertée de nouveau, Apple a indiqué en mai qu’un correctif avait été mis au point et serait appliqué dans les prochaines semaines, avant de se murer dans le silence.

• Une faille dans la fonction Hide My Email d’Apple peut révéler l’adresse principale

Tyler Murphy a alors contacté 404media pour médiatiser l’affaire, sans rien révéler sur la nature précise du problème afin de ne pas donner des idées à des malandrins. L’affaire a pris suffisamment d’ampleur pour qu’Apple se décide finalement à appliquer un correctif. Maintenant que la faille appartient au passé, le site explique qu’il suffisait d’envoyer un message à un utilisateur ciblé de « Masquer mon adresse e-mail » et que celui-ci soit rejeté comme spam pour pouvoir exploiter la faille.

« Nous ne pensons toutefois pas que tout risque soit désormais écarté », préviennent Tyler Murphy et Ben Weiner, le cofondateur de la société EasyOptOut. « Des e-mails non malveillants pouvaient être rejetés et révéler votre adresse masquée. Comme les journaux de transfert des messages sont souvent conservés, nous estimons que toute adresse masquée associée à une adresse créée avec “Masquer mon adresse e-mail” avant le 7 juillet 2026 a pu être exposée et pourrait encore figurer dans des journaux détenus par des tiers », précisent-ils.

Apple n’est donc peut-être pas encore au bout de ses peines. À cela s’ajoute une plainte (PDF) déposée en Californie le 17 juillet, qui accuse l’entreprise d’avoir trompé ses clients sur le niveau de confidentialité de la fonction « Masquer mon adresse e-mail », tout en la leur faisant payer.

Mise à jour — Un bug n’arrive jamais seul. Le développeur Jeff Johnson et MacGeneration ont mis la main sur une autre vulnérabilité qui touche directement le logiciel Mail d’Apple. Cette vulnérabilité permet à un plaisantin de récupérer l’adresse liée au compte Apple d’une personne qui ne souhaite pas la partager.

Le piège est très simple. Il suffit d’envoyer un courriel à l’adresse connue de la victime en ajoutant un en-tête spécifique qui active le bug. Le message affiche un bandeau « Ce message vous a été transféré via « Masquer mon adresse e-mail » », qui doit mettre la puce à l’oreille car il n’apparait habituellement pas.

Si l’utilisateur répond tout de même à l’e-mail malveillant depuis l’app Mail, son adresse « À: » sera celle du compte Apple… pas l’adresse d’origine à laquelle le courriel avait été envoyé. C’est embêtant, car on peut ne pas vouloir divulguer l’adresse de son compte Apple ou alors uniquement à des proches. Apple a été prévenue de ce nouveau bug.

Mardi matin, le site du Rassemblement national (RN) affichait les stigmates d’une intrusion : en page d’accueil, le visuel d’un communiqué daté du 15 juillet avait été remplacé par un logo revendiquant l’attaque : un chat stylisé, décoré de drapeaux du Maroc et d’Algérie, et accompagné d’un pseudonyme, 84City. Le texte de ce même communiqué avait quant à lui été supprimé.

Le parti incarné par Marine Le Pen pour l’échéance électorale de 2027 a remédié à cet affichage mardi en milieu de journée, et confirmé à France Info la survenue d’une attaque. Une source interne au parti précise que les vérifications menées jusqu’alors n’ont pas montré de vol de données personnelles « à ce stade ». Le RN indique par ailleurs son intention de déposer une plainte.

L’attaque se limite-t-elle à un simple « défaçage », c’est-à-dire une altération des éléments visibles du site ? Un internaute utilisant le pseudonyme 84City a posté lundi 20 juillet dans la soirée, sur un forum spécialisé, une annonce signalant la mise en vente d’une base de données soi-disant extraite du site du RN.

L’auteur du post évoque des données datées du jour-même, avec 12 tables issues du moteur WordPress du site, et 95 tables extraites d’une base de données MariaDB 11.8.8 opérée sous Debian. Il mentionne enfin huit tables associées à Gravity Forms, une extension WordPress utilisée pour la gestion de formulaires en ligne. L’annonce n’est cependant accompagnée d’aucun échantillon qui permettrait d’attester sa véracité.

La France Insoumise (LFI) a elle aussi subi une attaque informatique début mai, quelques jours après que son président, Jean-Luc Mélenchon, a annoncé sa candidature à l’élection présidentielle de 2027.

Rappelons que d’un point de vue réglementaire, les informations qui révèlent l’orientation politique relèvent de ce que le RGPD qualifie, dans son article 9, de « données sensibles ».

Mardi matin, le site du Rassemblement national (RN) affichait les stigmates d’une intrusion : en page d’accueil, le visuel d’un communiqué daté du 15 juillet avait été remplacé par un logo revendiquant l’attaque : un chat stylisé, décoré de drapeaux du Maroc et d’Algérie, et accompagné d’un pseudonyme, 84City. Le texte de ce même communiqué avait quant à lui été supprimé.

Le parti incarné par Marine Le Pen pour l’échéance électorale de 2027 a remédié à cet affichage mardi en milieu de journée, et confirmé à France Info la survenue d’une attaque. Une source interne au parti précise que les vérifications menées jusqu’alors n’ont pas montré de vol de données personnelles « à ce stade ». Le RN indique par ailleurs son intention de déposer une plainte.

L’attaque se limite-t-elle à un simple « défaçage », c’est-à-dire une altération des éléments visibles du site ? Un internaute utilisant le pseudonyme 84City a posté lundi 20 juillet dans la soirée, sur un forum spécialisé, une annonce signalant la mise en vente d’une base de données soi-disant extraite du site du RN.

L’auteur du post évoque des données datées du jour-même, avec 12 tables issues du moteur WordPress du site, et 95 tables extraites d’une base de données MariaDB 11.8.8 opérée sous Debian. Il mentionne enfin huit tables associées à Gravity Forms, une extension WordPress utilisée pour la gestion de formulaires en ligne. L’annonce n’est cependant accompagnée d’aucun échantillon qui permettrait d’attester sa véracité.

La France Insoumise (LFI) a elle aussi subi une attaque informatique début mai, quelques jours après que son président, Jean-Luc Mélenchon, a annoncé sa candidature à l’élection présidentielle de 2027.

Rappelons que d’un point de vue réglementaire, les informations qui révèlent l’orientation politique relèvent de ce que le RGPD qualifie, dans son article 9, de « données sensibles ».

Brand new war

Hugging Face a publié le 16 juillet 2026 une divulgation d’incident au sujet d’une intrusion dans une partie de son infrastructure de production. Selon l’entreprise, cette intrusion présentait une caractéristique inédite : elle a été pilotée de bout en bout par un système d’agent IA autonome.

Au constat de cette intrusion, Hugging Face en a opposé un autre : l’incident a été détecté et analysé en grande partie par la propre IA de l’éditeur.

Dans son compte rendu, l’entreprise indique avoir identifié un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants utilisés par ses services, tout en précisant que l’évaluation de l’impact sur les données de partenaires ou clients était encore en cours. Point important pour l’écosystème : aucune preuve d’altération des modèles, datasets (lots de données) ou Spaces publics destinés aux utilisateurs n’a été trouvée. La chaîne d’approvisionnement logicielle (images de conteneurs, paquets publiés) a été vérifiée et a été déclarée comme saine.

Comment les pirates sont-ils entrés ?

Le point d’entrée se situe dans le pipeline de traitement des datasets. Un jeu de données malveillant a exploité deux chemins d’exécution de code dans le traitement des datasets : un chargeur de dataset à exécution de code distant et une injection de template dans une configuration de dataset, avec pour finalité l’exécution du code sur un worker de traitement.

À partir de ce point d’ancrage, les pirates ont progressé vers un accès au niveau du nœud, récupéré des identifiants cloud et de cluster, puis se sont déplacés latéralement dans plusieurs clusters internes pendant plusieurs jours.

Mais qui a attaqué ? On ne le sait pas encore, mais l’entreprise évoque une campagne menée par un framework d’agents autonomes, semblant construit sur un harnais de recherche en sécurité offensive de type agentique, bien que le LLM utilisé reste inconnu à ce stade. Ce framework a exécuté plusieurs milliers d’actions individuelles à travers un ensemble de sandbox (bacs à sable) éphémères, avec un serveur C&C (command-and-control) auto-migrant hébergé sur des services publics. Hugging Face, c’est la matérialisation concrète du scénario d’« attaquant agentique » anticipé par le secteur.

Les actions entreprises

Comme toujours dans ce genre d’annonce, l’entreprise liste les actions entreprises pour juguler le problème et éviter qu’il se reproduise.

Hugging Face dit ainsi avoir corrigé les chemins d’exécution de code du dataset ayant permis l’accès initial, supprimé le point d’ancrage des pirates, reconstruit les nœuds compromis, révoqué et regénéré les identifiants affectés, déclenché une rotation préventive plus large des secrets (mots de passe et autres informations identifiantes), déployé des garde-fous et contrôles d’admission plus stricts sur les clusters, et amélioré la détection pour qu’un signal de sévérité élevée déclenche une alerte en quelques minutes, tous les jours. L’entreprise ajoute travailler avec des spécialistes externes en analyse de ce type d’incident (forensic) et a signalé l’incident aux autorités judiciaires.

Rappelons que ce n’est pas la première fois que Hugging Face est attaquée et qu’une partie de ses infrastructures est compromise. En juin 2024, la société avait averti qu’un sous-ensemble de secrets avait été dérobé et que des accès non autorisés avaient été détectés dans un certain nombre de Spaces. Elle recommandait alors l’actualisation de tous les jetons et clés d’authentification.

IA contre IA

Le sujet est devenu courant depuis plusieurs mois : l’IA générative, et plus particulièrement les agents, provoquent une rupture dans le domaine de la cybersécurité. Le sujet est particulièrement prégnant depuis l’arrivée du modèle Mythos d’Anthropic, accessible depuis le fameux projet Glasswing, auquel seules des organisations triées sur le volet peuvent accéder. Ce fut notamment le cas de Mozilla.

• Firefox 150 corrige 271 vulnérabilités repérées par Claude Mythos

Hugging Face indique ainsi avoir utilisé son propre pipeline de triage basé sur des LLM pour corréler les signaux de sécurité et détecter la compromission. Pour reconstituer l’attaque, l’entreprise a fait tourner des agents d’analyse LLM sur l’intégralité du journal d’actions de l’attaquant, comprenant plus de 17 000 événements enregistrés. Elle dit avoir réussi à reconstituer la chronologie, à extraire les indicateurs de compromission, à cartographier les identifiants touchés et à séparer l’impact réel de l’activité leurre.

Elle évoque également un « problème d’asymétrie » intéressant. Hugging Face a d’abord tenté d’utiliser des modèles frontières via des API commerciales, mais ces requêtes nécessitaient de soumettre de larges volumes de commandes d’attaque réelles, des charges utiles d’exploitation et des éléments C&C. Résultat ? Elles ont été bloquées par les garde-fous de sécurité des fournisseurs, incapables de distinguer les requêtes d’un analyste travaillant à la réponse à un incident de celles d’un attaquant.

Une « leçon » à tirer, selon Hugging Face

En conséquence, Hugging Face a fini par faire tourner l’analyse forensic sur le modèle chinois GLM 5.2, dont les poids ouverts ont fait couler pas mal d’encre (le cas se reproduit avec Kimi K3). Le LLM a été exécuté sur la propre infrastructure de l’entreprise, en local, sans lien avec l’extérieur.

Hugging Face en tire justement une leçon opérationnelle : mieux vaut disposer d’un modèle capable, exécutable sur sa propre infrastructure, validé et prêt avant un incident, autant pour éviter le blocage par les garde-fous que pour empêcher que les données de l’attaquant et les identifiants quittent l’environnement. Elle ajoute cependant qu’il ne s’agit pas d’un argument contre les mesures de sécurité des modèles hébergés, et indique avoir partagé ce retour avec les fournisseurs concernés.

« Les outils offensifs autonomes pilotés par l’IA ne sont plus théoriques. Cela réduit le coût de gestion d’une campagne large, patiente et en plusieurs étapes, et cela fonctionne à la vitesse de la machine. Défendre une plateforme en ligne signifie désormais traiter la surface de données et de modèles comme une surface d’attaque de premier ordre, et utiliser l’IA en défense pour suivre le rythme. Nous continuerons à y investir et à partager ce que nous apprenons », conclut Hugging Face.

Brand new war

Hugging Face a publié le 16 juillet 2026 une divulgation d’incident au sujet d’une intrusion dans une partie de son infrastructure de production. Selon l’entreprise, cette intrusion présentait une caractéristique inédite : elle a été pilotée de bout en bout par un système d’agent IA autonome.

Au constat de cette intrusion, Hugging Face en a opposé un autre : l’incident a été détecté et analysé en grande partie par la propre IA de l’éditeur.

Dans son compte rendu, l’entreprise indique avoir identifié un accès non autorisé à un ensemble limité de jeux de données internes et à plusieurs identifiants utilisés par ses services, tout en précisant que l’évaluation de l’impact sur les données de partenaires ou clients était encore en cours. Point important pour l’écosystème : aucune preuve d’altération des modèles, datasets (lots de données) ou Spaces publics destinés aux utilisateurs n’a été trouvée. La chaîne d’approvisionnement logicielle (images de conteneurs, paquets publiés) a été vérifiée et a été déclarée comme saine.

Comment les pirates sont-ils entrés ?

Le point d’entrée se situe dans le pipeline de traitement des datasets. Un jeu de données malveillant a exploité deux chemins d’exécution de code dans le traitement des datasets : un chargeur de dataset à exécution de code distant et une injection de template dans une configuration de dataset, avec pour finalité l’exécution du code sur un worker de traitement.

À partir de ce point d’ancrage, les pirates ont progressé vers un accès au niveau du nœud, récupéré des identifiants cloud et de cluster, puis se sont déplacés latéralement dans plusieurs clusters internes pendant plusieurs jours.

Mais qui a attaqué ? On ne le sait pas encore, mais l’entreprise évoque une campagne menée par un framework d’agents autonomes, semblant construit sur un harnais de recherche en sécurité offensive de type agentique, bien que le LLM utilisé reste inconnu à ce stade. Ce framework a exécuté plusieurs milliers d’actions individuelles à travers un ensemble de sandbox (bacs à sable) éphémères, avec un serveur C&C (command-and-control) auto-migrant hébergé sur des services publics. Hugging Face, c’est la matérialisation concrète du scénario d’« attaquant agentique » anticipé par le secteur.

Les actions entreprises

Comme toujours dans ce genre d’annonce, l’entreprise liste les actions entreprises pour juguler le problème et éviter qu’il se reproduise.

Hugging Face dit ainsi avoir corrigé les chemins d’exécution de code du dataset ayant permis l’accès initial, supprimé le point d’ancrage des pirates, reconstruit les nœuds compromis, révoqué et regénéré les identifiants affectés, déclenché une rotation préventive plus large des secrets (mots de passe et autres informations identifiantes), déployé des garde-fous et contrôles d’admission plus stricts sur les clusters, et amélioré la détection pour qu’un signal de sévérité élevée déclenche une alerte en quelques minutes, tous les jours. L’entreprise ajoute travailler avec des spécialistes externes en analyse de ce type d’incident (forensic) et a signalé l’incident aux autorités judiciaires.

Rappelons que ce n’est pas la première fois que Hugging Face est attaquée et qu’une partie de ses infrastructures est compromise. En juin 2024, la société avait averti qu’un sous-ensemble de secrets avait été dérobé et que des accès non autorisés avaient été détectés dans un certain nombre de Spaces. Elle recommandait alors l’actualisation de tous les jetons et clés d’authentification.

IA contre IA

Le sujet est devenu courant depuis plusieurs mois : l’IA générative, et plus particulièrement les agents, provoquent une rupture dans le domaine de la cybersécurité. Le sujet est particulièrement prégnant depuis l’arrivée du modèle Mythos d’Anthropic, accessible depuis le fameux projet Glasswing, auquel seules des organisations triées sur le volet peuvent accéder. Ce fut notamment le cas de Mozilla.

• Firefox 150 corrige 271 vulnérabilités repérées par Claude Mythos

Hugging Face indique ainsi avoir utilisé son propre pipeline de triage basé sur des LLM pour corréler les signaux de sécurité et détecter la compromission. Pour reconstituer l’attaque, l’entreprise a fait tourner des agents d’analyse LLM sur l’intégralité du journal d’actions de l’attaquant, comprenant plus de 17 000 événements enregistrés. Elle dit avoir réussi à reconstituer la chronologie, à extraire les indicateurs de compromission, à cartographier les identifiants touchés et à séparer l’impact réel de l’activité leurre.

Elle évoque également un « problème d’asymétrie » intéressant. Hugging Face a d’abord tenté d’utiliser des modèles frontières via des API commerciales, mais ces requêtes nécessitaient de soumettre de larges volumes de commandes d’attaque réelles, des charges utiles d’exploitation et des éléments C&C. Résultat ? Elles ont été bloquées par les garde-fous de sécurité des fournisseurs, incapables de distinguer les requêtes d’un analyste travaillant à la réponse à un incident de celles d’un attaquant.

Une « leçon » à tirer, selon Hugging Face

En conséquence, Hugging Face a fini par faire tourner l’analyse forensic sur le modèle chinois GLM 5.2, dont les poids ouverts ont fait couler pas mal d’encre (le cas se reproduit avec Kimi K3). Le LLM a été exécuté sur la propre infrastructure de l’entreprise, en local, sans lien avec l’extérieur.

Hugging Face en tire justement une leçon opérationnelle : mieux vaut disposer d’un modèle capable, exécutable sur sa propre infrastructure, validé et prêt avant un incident, autant pour éviter le blocage par les garde-fous que pour empêcher que les données de l’attaquant et les identifiants quittent l’environnement. Elle ajoute cependant qu’il ne s’agit pas d’un argument contre les mesures de sécurité des modèles hébergés, et indique avoir partagé ce retour avec les fournisseurs concernés.

« Les outils offensifs autonomes pilotés par l’IA ne sont plus théoriques. Cela réduit le coût de gestion d’une campagne large, patiente et en plusieurs étapes, et cela fonctionne à la vitesse de la machine. Défendre une plateforme en ligne signifie désormais traiter la surface de données et de modèles comme une surface d’attaque de premier ordre, et utiliser l’IA en défense pour suivre le rythme. Nous continuerons à y investir et à partager ce que nous apprenons », conclut Hugging Face.

Donc attendez je résume : Microsoft laisse LG pousser, via WindowsUpdate, des AdWares qui font de la publicité pour McAffee, cette sangsue inutile.

1) LG, connards. Ajoutés à la liste des marques à boycotter.
2) ALLÔ MICROSOFT, VOUS FOUTEZ QUOI ? Depuis quand vous laissez des AdWares être installés via WindowsUpdate ? Y'a plus personne qui vérifie ? Je croyais que la certification WHCP servait à trier le bon grain de l'ivraie ?

EDIT: Un article en français avec des détails : https://next.ink/248273/comment-un-simple-branchement-decran-illustre-un-vieux-probleme-de-windows/
(Permalink)

Piratée par un système d'agents IA autonomes, la plateforme Hugging Face a dû abandonner les modèles frontière propriétaires pour mener son enquête. Le passage à un modèle open weight a changé la donne.

Une faille monstrueuse sur WordPress.
(Permalink)

Faille de sécurité dans 7-Zip dans le traitement des fichiers XZ. Mettez à jour en 26.02.
(Permalink)

Sécurité : un chiffon imbibé d'huile peut spontanément prendre feu.
Toujours laisser dans l'eau.
(Permalink)

Des traces de compromission par Pegasus liées au Maroc ont été retrouvées sur les smartphones d’anciens ministres français en exercice entre 2019 et 2021.

En 2023, le juge d’instruction chargé du dossier Pegasus au sein du tribunal judiciaire de Paris avait classé sept ministres parmi 23 « victimes » de Pegasus au même rang que les journalistes de Mediapart Edwy Plenel et Lénaïg Bredoux.

La plateforme journalistique Forbidden Stories, qui avait révélé le scandale Pegasus, explique que des traces de compromissions du logiciel espion ont été retrouvées dans les smartphones des sept ministres : par exemple, dans l’iPhone XS de Sébastien Lecornu lorsqu’il était ministre des Collectivités territoriales, comme dans l’iPhone 12 de Florence Parly alors qu’elle était ministre des Armées.

Certaines de ces traces (des adresses emails utilisées en identifiant) correspondent aussi à celles laissées par l’utilisation du logiciel lorsque le Maroc a compromis le téléphone pour surveiller le journaliste Omar Radi, selon des éléments d’Amnesty Security Lab qui a élaboré une méthode de détection, ajoute Forbidden Stories.

Un courrier daté d’avril 2022 de la DGSE, qu’ont pu consulter nos confrères, confirme que le service a été « en mesure de rattacher certaines intrusions à l’activité de services de renseignement de pays clients de Pegasus et estim[e] qu’elles participent à des opérations d’espionnage portant atteinte aux intérêts fondamentaux de la Nation ».

En parallèle de cet espionnage de la France par le Maroc, les services français se montraient eux aussi intéressés pour l’utiliser : le ministère de la Justice, la DGSI et la direction du renseignement militaire (DRM) ont été considérés comme des clients potentiels en 2020. Un témoignage affirme que NSO proposait un tarif avoisinant 60/80 millions d’euros à la France pour ses services.

Forbidden Stories revient aussi sur l’utilisation de Pegasus pour cibler l’entourage de l’ex-président du Gabon Ali Bongo ainsi que sur les détails de l’acquisition de Pegasus par le Maroc.

Des traces de compromission par Pegasus liées au Maroc ont été retrouvées sur les smartphones d’anciens ministres français en exercice entre 2019 et 2021.

En 2023, le juge d’instruction chargé du dossier Pegasus au sein du tribunal judiciaire de Paris avait classé sept ministres parmi 23 « victimes » de Pegasus au même rang que les journalistes de Mediapart Edwy Plenel et Lénaïg Bredoux.

La plateforme journalistique Forbidden Stories, qui avait révélé le scandale Pegasus, explique que des traces de compromissions du logiciel espion ont été retrouvées dans les smartphones des sept ministres : par exemple, dans l’iPhone XS de Sébastien Lecornu lorsqu’il était ministre des Collectivités territoriales, comme dans l’iPhone 12 de Florence Parly alors qu’elle était ministre des Armées.

Certaines de ces traces (des adresses emails utilisées en identifiant) correspondent aussi à celles laissées par l’utilisation du logiciel lorsque le Maroc a compromis le téléphone pour surveiller le journaliste Omar Radi, selon des éléments d’Amnesty Security Lab qui a élaboré une méthode de détection, ajoute Forbidden Stories.

Un courrier daté d’avril 2022 de la DGSE, qu’ont pu consulter nos confrères, confirme que le service a été « en mesure de rattacher certaines intrusions à l’activité de services de renseignement de pays clients de Pegasus et estim[e] qu’elles participent à des opérations d’espionnage portant atteinte aux intérêts fondamentaux de la Nation ».

En parallèle de cet espionnage de la France par le Maroc, les services français se montraient eux aussi intéressés pour l’utiliser : le ministère de la Justice, la DGSI et la direction du renseignement militaire (DRM) ont été considérés comme des clients potentiels en 2020. Un témoignage affirme que NSO proposait un tarif avoisinant 60/80 millions d’euros à la France pour ses services.

Forbidden Stories revient aussi sur l’utilisation de Pegasus pour cibler l’entourage de l’ex-président du Gabon Ali Bongo ainsi que sur les détails de l’acquisition de Pegasus par le Maroc.