Selon Politico, la Commission européenne préparerait un dépôt de plainte contre la France, l’Espagne et plusieurs autres pays. La raison ? Le retard pris sur la transposition de la directive NIS2, qui doit entrainer une hausse massive du niveau de cybersécurité sur le Vieux continent.

Toujours selon nos confrères, la Commission prévoirait de porter l’affaire devant la Cour de justice de l’Union européenne (CJUE) soit juste avant les congés d’été, soit juste après. Politico cite un responsable de la Commission, qui a souhaité garder l’anonymat.

La Commission n’a pas directement confirmé, le porte-parole Thomas Regnier indiquant simplement que « la Commission pourrait saisir la Cour de justice à l’encontre de certains États membres », puisque le délai de transposition a expiré en octobre 2024. Cependant, Politico cite un responsable français selon lequel le secrétariat général des affaires européennes « prépare sa défense devant la CJUE ».

Pourquoi un tel retard en France ? Parce que la directive NIS2 n’est pas transposée seule. Comme nous l’avons indiqué à plusieurs reprises en 2025, elle s’effectue sur trois textes en même temps : NIS2, qui élargit radicalement le périmètre d’action (de 600 entités sous NIS1 à 15 000), DORA pour la résilience du secteur financier et REC pour les entités critiques.

• Cybersécurité : la transposition des directives NIS2, DORA et REC passe le Sénat

Or, comme nous le relations en mars dernier, il existe un point de clivage : l’article 16 bis, qui consacre la protection du chiffrement et interdit l’imposition de portes dérobées dans les messageries. La Commission supérieure du numérique et des postes (CSNP) évoquait alors une opposition du gouvernement. Le député Philippe Latombe, impliqué dans la transposition, critiquait pour sa part vertement la DGSI, qui cherchait à supprimer cet article.

Selon Politico, la Commission européenne préparerait un dépôt de plainte contre la France, l’Espagne et plusieurs autres pays. La raison ? Le retard pris sur la transposition de la directive NIS2, qui doit entrainer une hausse massive du niveau de cybersécurité sur le Vieux continent.

Toujours selon nos confrères, la Commission prévoirait de porter l’affaire devant la Cour de justice de l’Union européenne (CJUE) soit juste avant les congés d’été, soit juste après. Politico cite un responsable de la Commission, qui a souhaité garder l’anonymat.

La Commission n’a pas directement confirmé, le porte-parole Thomas Regnier indiquant simplement que « la Commission pourrait saisir la Cour de justice à l’encontre de certains États membres », puisque le délai de transposition a expiré en octobre 2024. Cependant, Politico cite un responsable français selon lequel le secrétariat général des affaires européennes « prépare sa défense devant la CJUE ».

Pourquoi un tel retard en France ? Parce que la directive NIS2 n’est pas transposée seule. Comme nous l’avons indiqué à plusieurs reprises en 2025, elle s’effectue sur trois textes en même temps : NIS2, qui élargit radicalement le périmètre d’action (de 600 entités sous NIS1 à 15 000), DORA pour la résilience du secteur financier et REC pour les entités critiques.

• Cybersécurité : la transposition des directives NIS2, DORA et REC passe le Sénat

Or, comme nous le relations en mars dernier, il existe un point de clivage : l’article 16 bis, qui consacre la protection du chiffrement et interdit l’imposition de portes dérobées dans les messageries. La Commission supérieure du numérique et des postes (CSNP) évoquait alors une opposition du gouvernement. Le député Philippe Latombe, impliqué dans la transposition, critiquait pour sa part vertement la DGSI, qui cherchait à supprimer cet article.

L'histoire sans fin

Microsoft a dû bloquer l’accès aux dépôts GitHub de plus de 70 de ses propres projets. Certains d’entre eux ont été piratés au cours d’une campagne de vols d’identifiants d’outils d’IA générative nommée Miasma.

L’éditeur de GitHub n’est pas épargné par les attaques actuelles contre la supply chain de logiciels open source. Ainsi, Microsoft a dû désactiver l’accès à plus de 70 de ses propres dépôts sur GitHub, comme l’expliquait le site Open Source Malware.

Dans le lot, le dépôt d’Azure nommé « functions-action » qui permet de déployer le code d’un projet utilisant « Azure Functions » ou encore le framework Durable Task, « utilisé activement en production par de nombreuses équipes, y compris les équipes d’ingénierie au sein de Microsoft ». Ceux-ci sont maintenant de nouveau accessibles comme d’autres, Microsoft redonnant accès à ses projets au fur et à mesure des corrections et vérifications.

Microsoft avait identifié l’attaque chez Red Hat

Une bonne partie de ces dépôts ont été touchés par la campagne de vol d’identifiants « Miasma », selon Open Source Malware et l’entreprise de sécurité StepSecurity. Ironiquement, l’équipe de recherche en sécurité de Microsoft avait détecté que cette attaque visait la chaîne d’approvisionnement npm de Red Hat, touchant « 32 paquets modifiés de manière malveillante dans plus de 90 versions relevant du périmètre npm @redhat-cloud-services », expliquait l’entreprise le 2 juin dernier.

« Un pipeline CI/CD (Continuous Integration/Continuous Delivery) a permis à des pirates de publier des paquets infectés par des chevaux de Troie via le flux de publication légitime OpenID Connect (OIDC) de GitHub Actions. Ainsi, ces paquets malveillants portaient des signatures de provenance authentiques tout en intégrant le marqueur de campagne « Miasma : The Spreading Blight » », expliquait Microsoft concernant les paquets npm de Red Hat.

• La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets
• Hackerbot-claw : un bot exploite GitHub Actions et vide le dépôt de Trivy

Mais l’entreprise de Redmond a été attaquée à son tour. StepSecurity a identifié le commit poussé dans le dépôt Azure/durabletask à l’aide d’un compte de contributeur piraté. « Cette modification a ajouté cinq fichiers destinés à permettre l’exécution automatique du code dans quatre outils de développement différents », explique l’entreprise dans son billet de blog et ajoute : « Cloner le dépôt ne présente aucun risque. L’ouvrir, en revanche, n’est pas sans danger ». Le code s’exécute automatiquement lorsqu’un développeur ouvre le dépôt dans Claude Code, Gemini CLI, Cursor ou VS Code et cherche à récupérer des identifiants.

Step Security fait le lien avec l’attaque Mini Shai-Hulud menée par TeamPCP, notamment car les deux utilisent un même domaine secondaire : C2 t.m-kosche[.]com. Elle explique aussi que « le compte piraté est celui du même contributeur dont les identifiants ont été utilisés lors de l’attaque contre PyPI du 19 mai » que l’entreprise de sécurité avait identifiée dans le dépôt du SDK durabletask maintenu par Microsoft.

La compromission des identifiants développeurs comme porte d’entrée

« Le génie de ce ver Miasma réside dans la manière dont il s’est fondu dans les flux de travail légitimes », explique Cloudsmith, une autre entreprise de sécurité qui a analysé le problème. « Il n’exploite aucune faille logicielle de GitHub ou de npm. Il tire plutôt parti du modèle de confiance sous-jacent de l’écosystème d’ingénierie moderne. La compromission des identifiants de développeurs a permis de demander un jeton OIDC GitHub légitime. Cela a été suivi de la publication d’une version malveillante dotée d’une provenance SLSA valide, ce qui a finalement conduit les scanners conventionnels à la considérer comme une mise à jour de routine fiable. En volant les identifiants légitimes du responsable de maintenance, le ver a pu agir exactement comme l’aurait fait un éditeur authentifié », ajoute Cloudsmith.

Le billet de l’entreprise explique aussi que Miasma génère une charge utile chiffrée de manière unique pour chaque infection, ce qui permet de passer outre les outils de détection traditionnels.

Microsoft a confirmé à 404 Media avoir désactivé les dépôts concernés. Interrogée par TechCrunch, l’entreprise explique : « Nous avons temporairement supprimé certains dépôts pendant que nous enquêtions sur la présence éventuelle de contenus malveillants ». « Certains de ces dépôts ont été rétablis après vérification, tandis que d’autres pourraient rester hors ligne pendant la poursuite des travaux », explique le porte-parole de l’entreprise, Ben Hope.

« Dans le cadre de notre enquête, nous avons contacté un petit nombre de clients susceptibles d’avoir téléchargé du contenu provenant des dépôts concernés. Nous poursuivrons notre enquête et, si nous identifions d’autres éléments nécessitant une intervention de la part des clients, nous les contacterons directement via nos canaux d’assistance habituels », ajoute-t-il, sans préciser ce « petit nombre ».

L'histoire sans fin

Microsoft a dû bloquer l’accès aux dépôts GitHub de plus de 70 de ses propres projets. Certains d’entre eux ont été piratés au cours d’une campagne de vols d’identifiants d’outils d’IA générative nommée Miasma.

L’éditeur de GitHub n’est pas épargné par les attaques actuelles contre la supply chain de logiciels open source. Ainsi, Microsoft a dû désactiver l’accès à plus de 70 de ses propres dépôts sur GitHub, comme l’expliquait le site Open Source Malware.

Dans le lot, le dépôt d’Azure nommé « functions-action » qui permet de déployer le code d’un projet utilisant « Azure Functions » ou encore le framework Durable Task, « utilisé activement en production par de nombreuses équipes, y compris les équipes d’ingénierie au sein de Microsoft ». Ceux-ci sont maintenant de nouveau accessibles comme d’autres, Microsoft redonnant accès à ses projets au fur et à mesure des corrections et vérifications.

Microsoft avait identifié l’attaque chez Red Hat

Une bonne partie de ces dépôts ont été touchés par la campagne de vol d’identifiants « Miasma », selon Open Source Malware et l’entreprise de sécurité StepSecurity. Ironiquement, l’équipe de recherche en sécurité de Microsoft avait détecté que cette attaque visait la chaîne d’approvisionnement npm de Red Hat, touchant « 32 paquets modifiés de manière malveillante dans plus de 90 versions relevant du périmètre npm @redhat-cloud-services », expliquait l’entreprise le 2 juin dernier.

« Un pipeline CI/CD (Continuous Integration/Continuous Delivery) a permis à des pirates de publier des paquets infectés par des chevaux de Troie via le flux de publication légitime OpenID Connect (OIDC) de GitHub Actions. Ainsi, ces paquets malveillants portaient des signatures de provenance authentiques tout en intégrant le marqueur de campagne « Miasma : The Spreading Blight » », expliquait Microsoft concernant les paquets npm de Red Hat.

• La saga continue : un paquet NPM vérolé de Bitwarden CLI a dérobé des secrets
• Hackerbot-claw : un bot exploite GitHub Actions et vide le dépôt de Trivy

Mais l’entreprise de Redmond a été attaquée à son tour. StepSecurity a identifié le commit poussé dans le dépôt Azure/durabletask à l’aide d’un compte de contributeur piraté. « Cette modification a ajouté cinq fichiers destinés à permettre l’exécution automatique du code dans quatre outils de développement différents », explique l’entreprise dans son billet de blog et ajoute : « Cloner le dépôt ne présente aucun risque. L’ouvrir, en revanche, n’est pas sans danger ». Le code s’exécute automatiquement lorsqu’un développeur ouvre le dépôt dans Claude Code, Gemini CLI, Cursor ou VS Code et cherche à récupérer des identifiants.

Step Security fait le lien avec l’attaque Mini Shai-Hulud menée par TeamPCP, notamment car les deux utilisent un même domaine secondaire : C2 t.m-kosche[.]com. Elle explique aussi que « le compte piraté est celui du même contributeur dont les identifiants ont été utilisés lors de l’attaque contre PyPI du 19 mai » que l’entreprise de sécurité avait identifiée dans le dépôt du SDK durabletask maintenu par Microsoft.

La compromission des identifiants développeurs comme porte d’entrée

« Le génie de ce ver Miasma réside dans la manière dont il s’est fondu dans les flux de travail légitimes », explique Cloudsmith, une autre entreprise de sécurité qui a analysé le problème. « Il n’exploite aucune faille logicielle de GitHub ou de npm. Il tire plutôt parti du modèle de confiance sous-jacent de l’écosystème d’ingénierie moderne. La compromission des identifiants de développeurs a permis de demander un jeton OIDC GitHub légitime. Cela a été suivi de la publication d’une version malveillante dotée d’une provenance SLSA valide, ce qui a finalement conduit les scanners conventionnels à la considérer comme une mise à jour de routine fiable. En volant les identifiants légitimes du responsable de maintenance, le ver a pu agir exactement comme l’aurait fait un éditeur authentifié », ajoute Cloudsmith.

Le billet de l’entreprise explique aussi que Miasma génère une charge utile chiffrée de manière unique pour chaque infection, ce qui permet de passer outre les outils de détection traditionnels.

Microsoft a confirmé à 404 Media avoir désactivé les dépôts concernés. Interrogée par TechCrunch, l’entreprise explique : « Nous avons temporairement supprimé certains dépôts pendant que nous enquêtions sur la présence éventuelle de contenus malveillants ». « Certains de ces dépôts ont été rétablis après vérification, tandis que d’autres pourraient rester hors ligne pendant la poursuite des travaux », explique le porte-parole de l’entreprise, Ben Hope.

« Dans le cadre de notre enquête, nous avons contacté un petit nombre de clients susceptibles d’avoir téléchargé du contenu provenant des dépôts concernés. Nous poursuivrons notre enquête et, si nous identifions d’autres éléments nécessitant une intervention de la part des clients, nous les contacterons directement via nos canaux d’assistance habituels », ajoute-t-il, sans préciser ce « petit nombre ».

« Fighting Spyware », as usual

Placée sur liste noire par l’administration Biden depuis 2021, l’ex-entreprise israélienne NSO avait été condamnée l’an passé à ne plus tenter de pirater la messagerie de Meta. Depuis rachetée par un ancien avocat de Donald Trump, elle viendrait pourtant de recommencer.

Dans un communiqué intitulé « Lutte contre les logiciels espions : une mise à jour de WhatsApp », la messagerie de Meta vient d’annoncer avoir de nouveau détecté et déjoué des tentatives d’hameçonnage personnalisé (ou « spear phishing ») liées à NSO, l’ex-entreprise israélienne connue pour son logiciel espion Pegasus et figurant sur la liste noire du gouvernement américain depuis 2021.

L’administration Biden lui avait alors reproché d’avoir « commercialisé un outil numérique mis au service de la répression de dissidents, militants et journalistes » et d’avoir « participé à des activités contraires à la sécurité nationale ou aux intérêts de politique étrangère des États-Unis ».

• Pegasus : les États-Unis placent NSO sur « liste noire »

WhatsApp avait pourtant réussi à faire condamner NSO par la justice états-unienne, en juillet 2025, aux termes d’un procès entamé par Meta il y a six ans, pour avoir infecté environ 1 400 smartphones, dont des journalistes, militants des droits humains et dissidents.

• Pegasus a bien infecté environ 1 400 smartphones via WhatsApp en 2019
• Pegasus : la Justice états-unienne condamne NSO Group pour avoir piraté WhatsApp

En octobre, l’amende de 168 millions de dollars avait été réduite à 4 millions, mais le juge avait ordonné à NSO de cesser de cibler WhatsApp. Une décision qui, selon la société lors de sa défense, risquait de la conduire à la faillite. NSO avait fait appel de la décision, et demandé un sursis.

Le nouveau président de NSO est un ancien avocat de Donald Trump

En novembre, l’entreprise annonçait qu’un groupe d’investisseurs dirigé par un producteur hollywoodien venait d’investir des dizaines de millions de dollars afin de prendre le contrôle de l’entreprise israélienne.

Mais, et surtout, NSO se dotait d’un nouveau président exécutif, David Friedman, un ancien avocat d’affaires ayant notamment défendu les intérêts de Donald Trump dans le cadre des faillites de ses casinos d’Atlantic City.

Il avait ensuite été nommé ambassadeur des États-Unis en Israël de 2017 à 2021, sous la première présidence de Donald Trump. Une nomination qui avait alors été dénoncée par cinq anciens ambassadeurs des États-Unis en Israël, notamment parce que l’impétrant se présentait comme un fervent partisan des implantations israéliennes et de l’annexion de la Cisjordanie.

• NSO, l’éditeur du logiciel espion Pegasus, passe sous pavillon états-unien, et trumpien

Des noms de domaine inspirés de Gaza, des Frères musulmans et de France24

« Lorsqu’une entreprise malveillante figurant sur la liste des entités du gouvernement américain continue de défier les tribunaux américains, les restrictions en vigueur doivent rester strictement en vigueur », rappelle Meta dans son communiqué :

« Les assouplir compromettrait la sécurité nationale des États-Unis et mettrait en danger les entreprises américaines ainsi que des milliards de personnes à travers le monde qui dépendent de communications sécurisées. »

Meta indique avoir demandé au tribunal de « condamner NSO pour outrage au tribunal pour avoir enfreint une injonction permanente qui lui interdisait de cibler WhatsApp et ses utilisateurs ».

L’entreprise souligne qu’elle a reçu le mois dernier le soutien de 12 ONG de premier plan spécialisées dans la défense des droits civiques – dont Access Now et le Knight Institute – afin de s’opposer à l’appel interjeté par NSO contre l’injonction permanente.

Meta a par ailleurs rendu public les noms de domaine utilisés par NSO pour tenter d’installer son logiciel espion sur les terminaux de ses cibles : hxxps://ghazacast[.]com (pouvant potentiellement faire penser à un dispositif de broadcast associé à la bande de Ghaza), hxxps://ikhwancast[.]com (inspiré des noms de domaine des sites web des Frères musulmans), et hxxps://fr24cast[.]com (en lien avec France24 ?).

Un représentant de Meta précise au New York Times avoir été alerté de ces tentatives de « spear phishing » suspectes par des victimes potentielles, qu’elles ont échoué et semblaient concerner moins de dix utilisateurs de WhatsApp, principalement en Jordanie et au Liban.

« Fighting Spyware », as usual

Placée sur liste noire par l’administration Biden depuis 2021, l’ex-entreprise israélienne NSO avait été condamnée l’an passé à ne plus tenter de pirater la messagerie de Meta. Depuis rachetée par un ancien avocat de Donald Trump, elle viendrait pourtant de recommencer.

Dans un communiqué intitulé « Lutte contre les logiciels espions : une mise à jour de WhatsApp », la messagerie de Meta vient d’annoncer avoir de nouveau détecté et déjoué des tentatives d’hameçonnage personnalisé (ou « spear phishing ») liées à NSO, l’ex-entreprise israélienne connue pour son logiciel espion Pegasus et figurant sur la liste noire du gouvernement américain depuis 2021.

L’administration Biden lui avait alors reproché d’avoir « commercialisé un outil numérique mis au service de la répression de dissidents, militants et journalistes » et d’avoir « participé à des activités contraires à la sécurité nationale ou aux intérêts de politique étrangère des États-Unis ».

• Pegasus : les États-Unis placent NSO sur « liste noire »

WhatsApp avait pourtant réussi à faire condamner NSO par la justice états-unienne, en juillet 2025, aux termes d’un procès entamé par Meta il y a six ans, pour avoir infecté environ 1 400 smartphones, dont des journalistes, militants des droits humains et dissidents.

• Pegasus a bien infecté environ 1 400 smartphones via WhatsApp en 2019
• Pegasus : la Justice états-unienne condamne NSO Group pour avoir piraté WhatsApp

En octobre, l’amende de 168 millions de dollars avait été réduite à 4 millions, mais le juge avait ordonné à NSO de cesser de cibler WhatsApp. Une décision qui, selon la société lors de sa défense, risquait de la conduire à la faillite. NSO avait fait appel de la décision, et demandé un sursis.

Le nouveau président de NSO est un ancien avocat de Donald Trump

En novembre, l’entreprise annonçait qu’un groupe d’investisseurs dirigé par un producteur hollywoodien venait d’investir des dizaines de millions de dollars afin de prendre le contrôle de l’entreprise israélienne.

Mais, et surtout, NSO se dotait d’un nouveau président exécutif, David Friedman, un ancien avocat d’affaires ayant notamment défendu les intérêts de Donald Trump dans le cadre des faillites de ses casinos d’Atlantic City.

Il avait ensuite été nommé ambassadeur des États-Unis en Israël de 2017 à 2021, sous la première présidence de Donald Trump. Une nomination qui avait alors été dénoncée par cinq anciens ambassadeurs des États-Unis en Israël, notamment parce que l’impétrant se présentait comme un fervent partisan des implantations israéliennes et de l’annexion de la Cisjordanie.

• NSO, l’éditeur du logiciel espion Pegasus, passe sous pavillon états-unien, et trumpien

Des noms de domaine inspirés de Gaza, des Frères musulmans et de France24

« Lorsqu’une entreprise malveillante figurant sur la liste des entités du gouvernement américain continue de défier les tribunaux américains, les restrictions en vigueur doivent rester strictement en vigueur », rappelle Meta dans son communiqué :

« Les assouplir compromettrait la sécurité nationale des États-Unis et mettrait en danger les entreprises américaines ainsi que des milliards de personnes à travers le monde qui dépendent de communications sécurisées. »

Meta indique avoir demandé au tribunal de « condamner NSO pour outrage au tribunal pour avoir enfreint une injonction permanente qui lui interdisait de cibler WhatsApp et ses utilisateurs ».

L’entreprise souligne qu’elle a reçu le mois dernier le soutien de 12 ONG de premier plan spécialisées dans la défense des droits civiques – dont Access Now et le Knight Institute – afin de s’opposer à l’appel interjeté par NSO contre l’injonction permanente.

Meta a par ailleurs rendu public les noms de domaine utilisés par NSO pour tenter d’installer son logiciel espion sur les terminaux de ses cibles : hxxps://ghazacast[.]com (pouvant potentiellement faire penser à un dispositif de broadcast associé à la bande de Ghaza), hxxps://ikhwancast[.]com (inspiré des noms de domaine des sites web des Frères musulmans), et hxxps://fr24cast[.]com (en lien avec France24 ?).

Un représentant de Meta précise au New York Times avoir été alerté de ces tentatives de « spear phishing » suspectes par des victimes potentielles, qu’elles ont échoué et semblaient concerner moins de dix utilisateurs de WhatsApp, principalement en Jordanie et au Liban.

La direction interministérielle du numérique (Dinum) a signalé lundi 8 juin après-midi un incident de sécurité constaté au niveau de Tchap, l’application de messagerie sécurisée consacrée à l’été 2025 comme l’outil de référence à utiliser pour toute la fonction publique.

L’incident aurait été constaté la veille, dimanche 7 juin, par l’ANSSI. Celle-ci a « détecté une compromission du service Tchap de messagerie instantanée chiffrée de l’État, à la suite d’une usurpation de compte ».

« A ce stade, le compte à l’origine des requêtes malveillantes a été identifié. Il a été immédiatement bloqué afin de supprimer l’accès persistant de l’attaquant et permettre une analyse approfondie des données auxquelles il a pu accéder. Les investigations se poursuivent, notamment par l’étude des journaux d’événements (logs), pour identifier les conversations auxquelles l’attaquant a pu accéder et la nature des données exfiltrées. », écrit la Dinum.

L’incident n’aurait donc pas affecté les serveurs de la messagerie : il semble localisé au niveau d’un compte utilisateur, qui a donc pu être utilisé pour consulter les salons publics hébergés sur Tchap. Rappelons que cette messagerie est basée sur le protocole Matrix, qui permet un chiffrement bout en bout des échanges. Dans l’implémentation retenue pour Tchap, celui-ci ne concerne cependant pas les conversations publiques.

« Un message a été transmis à l’ensemble des utilisateurs de Tchap rappelant qu’une conversation publique (ou « salon public ») peut être trouvée et rejointe par tout utilisateur et que son contenu n’y est pas chiffré. Conformément aux modalités d’utilisation de Tchap, aucune information personnelle, sensible ou couverte par le secret professionnel ne doit y être échangée : ces échanges doivent être réservés aux salons privés », rappelle à ce sujet la Dinum, qui ajoute avoir notifié l’incident à la Cnil.

Une annonce publiée sur un forum dédié aux vols de données revendiquait, dimanche, l’exfiltration d’un jeu de données issues de la messagerie Tchap comprenant notamment les profils de 73 000 agents avec un certain nombre d’informations professionnelles (email, institution de rattachement, etc.), un solde de 643 000 messages, et de nombreux fichiers multimédias. La véracité de ces allégations n’a pas été confirmée.

• La CNIL confirme un record de fuites de données en 2025 et promet plus de contrôles

La direction interministérielle du numérique (Dinum) a signalé lundi 8 juin après-midi un incident de sécurité constaté au niveau de Tchap, l’application de messagerie sécurisée consacrée à l’été 2025 comme l’outil de référence à utiliser pour toute la fonction publique.

L’incident aurait été constaté la veille, dimanche 7 juin, par l’ANSSI. Celle-ci a « détecté une compromission du service Tchap de messagerie instantanée chiffrée de l’État, à la suite d’une usurpation de compte ».

« A ce stade, le compte à l’origine des requêtes malveillantes a été identifié. Il a été immédiatement bloqué afin de supprimer l’accès persistant de l’attaquant et permettre une analyse approfondie des données auxquelles il a pu accéder. Les investigations se poursuivent, notamment par l’étude des journaux d’événements (logs), pour identifier les conversations auxquelles l’attaquant a pu accéder et la nature des données exfiltrées. », écrit la Dinum.

L’incident n’aurait donc pas affecté les serveurs de la messagerie : il semble localisé au niveau d’un compte utilisateur, qui a donc pu être utilisé pour consulter les salons publics hébergés sur Tchap. Rappelons que cette messagerie est basée sur le protocole Matrix, qui permet un chiffrement bout en bout des échanges. Dans l’implémentation retenue pour Tchap, celui-ci ne concerne cependant pas les conversations publiques.

« Un message a été transmis à l’ensemble des utilisateurs de Tchap rappelant qu’une conversation publique (ou « salon public ») peut être trouvée et rejointe par tout utilisateur et que son contenu n’y est pas chiffré. Conformément aux modalités d’utilisation de Tchap, aucune information personnelle, sensible ou couverte par le secret professionnel ne doit y être échangée : ces échanges doivent être réservés aux salons privés », rappelle à ce sujet la Dinum, qui ajoute avoir notifié l’incident à la Cnil.

Une annonce publiée sur un forum dédié aux vols de données revendiquait, dimanche, l’exfiltration d’un jeu de données issues de la messagerie Tchap comprenant notamment les profils de 73 000 agents avec un certain nombre d’informations professionnelles (email, institution de rattachement, etc.), un solde de 643 000 messages, et de nombreux fichiers multimédias. La véracité de ces allégations n’a pas été confirmée.

• La CNIL confirme un record de fuites de données en 2025 et promet plus de contrôles

OpenAI a déployé deux nouvelles options de sécurité pour les comptes ChatGPT : un mode de verrouillage pour limiter les risques d'exfiltration liés aux injections de prompts, et une fonctionnalité de gestion des sessions actives ouverte à tous.

Dans un article paru le 7 juin 2026, le quotidien britannique The Guardian décrit comment des escrocs sont parvenus à faire remonter des boutiques clonées dans les réponses de ChatGPT. Une technique qui a exploité à la fois les failles des LLM et la disparition d'une marque emblématique.

Dans un billet de blog publié le 4 juin 2026, les chercheurs en sécurité de Sansec racontent comment des pirates informatiques sont parvenus à détourner Stripe pour en faire leur propre infrastructure de vol de données bancaires.

Dans un article publié le 3 juin 2026, des chercheurs de SafeBreach ont prouvé comment de simples notifications pouvaient suffire à manipuler Google Gemini. En exploitant le résumé vocal des messages, ils sont notamment parvenus à injecter des instructions invisibles, capables de tromper l’utilisateur à son insu.

• lien nᵒ 1 : Site de Rust Paris

Commentaires : voir le flux Atom ouvrir dans le navigateur

C’est bon, j’ai mis Password123!

Les gestionnaires de mots de passe permettent d’utiliser des mots de passe différents et complexes pour tous les services. Ils doivent eux aussi être protégés par un mot de passe maître, qui est parfois le dernier rempart contre les pirates. Une fuite de données chez Dashlane l’illustre parfaitement.

Après LastPass fin 2022, c’est au tour de Dashlane d’être victime d’une fuite de données : « Les attaquants ont pu télécharger une copie des coffres-forts chiffrés de moins de 20 utilisateurs sur un forfait personnel », reconnait l’entreprise.

Des coffres-forts chiffrés dans la nature

« À partir du dimanche 31 mai 2026, un pirate a lancé une attaque par force brute contre certains comptes d’utilisateurs de Dashlane », explique l’entreprise. L’attaquant essayait de casser l’authentification à deux facteurs afin d’enregistrer de nouveaux appareils sur des comptes d’utilisateurs, pour ensuite accéder aux données.

Bien évidemment, des protections ont permis de limiter l’attaque – mais pas de la bloquer totalement : « En raison du nombre élevé de tentatives d’accès aux comptes utilisateurs, les contrôles de sécurité de Dashlane ont automatiquement verrouillé les comptes ciblés par l’attaque », explique Dashlane.

Des comptes ont été suspendus de manière temporaire, mais surtout pour une vingtaine de clients le coffre-fort a été dérobé. Ils ont tous été déjà contactés individuellement par Dashlane.

Quels sont les risques ?

Avec les coffres-forts chiffrés, le ou les pirates ne peuvent pas faire grand-chose, sauf à réussir à les ouvrir évidemment. Ils accéderaient alors à l’intégralité des informations qu’ils contiennent : mots de passe, identifiants… une vraie caverne d’Alibaba.

Pour arriver à leurs fins, ils peuvent tenter de faire du phishing afin que vous « donniez » involontairement votre mot de passe maître, mais aussi tenter de passer en force.

Brutale, cette méthode consiste à tester toutes les combinaisons possibles jusqu’à trouver la bonne. En théorie, cela finit toujours par fonctionner. En pratique, il faut un temps quasi infini selon la taille et la complexité de votre mot de passe. On parle aussi d’entropie.

Autant dire que si votre mot de passe est « password123 », il ne tiendra même pas quelques secondes. Avec une copie de votre coffre-fort en sa possession, un pirate peut effectuer autant de tentatives qu’il le souhaite jusqu’à réussir à trouver le bon mot de passe et ainsi percer les protections.

Des années plus tard, la fuite Lastpass fait toujours des victimes

La fuite de Lastpass fin 2022 en est un parfait exemple. Cette fuite avait encore des conséquences en 2025, comme le rapporte BleepingComputer : « Plutôt que le portefeuille [de cryptomonnaie, qui est aussi parfois stocké dans les coffres-forts, ndlr] soit vidé immédiatement après une brèche, les vols se sont multipliés par vagues des mois ou des années plus tard, illustrant comment les attaquants décryptaient progressivement les coffres ».

Une autre manière de le dire : si votre coffre-fort est dans la nature, il est plus que recommandé de changer l’intégralité des secrets et mots de passe qui y sont enregistrés. Un pirate pourrait en forcer la porte maintenant comme dans quelques années quand la puissance de calcul coutera bien moins chère, par exemple.

Votre mot de passe maître doit être fort et robuste !

Dashlane reconnait ne pas avoir « d’exigences spécifiques pour les mots de passe maîtres », mais précise néanmoins s’appuyer sur « l’algorithme zxcvbn [de Daniel Lowe Wheeler chez Dropbox, ndlr] afin d’évaluer la sécurité de votre mot de passe lors de sa création ». L’entreprise prodigue aussi quelques conseils. Next a aussi des dossiers sur le sujet.

• Choisir un bon mot de passe : les règles à connaître, les pièges à éviter
• Phrases de passe : l’ANSSI passe en mode 2.0

Les clients de Dashlane sont les victimes, mais cette affaire rappelle l’importance du mot de passe maître qui sera le dernier rempart en cas de fuite de données. C’est valable quel que soit le gestionnaire utilisé, y compris (et surtout) en autohébergé. Si vous autohébergez un gestionnaire, ne sous-estimez surtout pas le mot de passe maitre.

• [Tuto] Auto-héberger son gestionnaire de mots de passe avec Vaultwarden (Bitwarden)
• #Nextpresso : on installe Vaultwarden sur une VM gratuite Google et Oracle… ça marche ?

C’est bon, j’ai mis Password123!

Les gestionnaires de mots de passe permettent d’utiliser des mots de passe différents et complexes pour tous les services. Ils doivent eux aussi être protégés par un mot de passe maître, qui est parfois le dernier rempart contre les pirates. Une fuite de données chez Dashlane l’illustre parfaitement.

Après LastPass fin 2022, c’est au tour de Dashlane d’être victime d’une fuite de données : « Les attaquants ont pu télécharger une copie des coffres-forts chiffrés de moins de 20 utilisateurs sur un forfait personnel », reconnait l’entreprise.

Des coffres-forts chiffrés dans la nature

« À partir du dimanche 31 mai 2026, un pirate a lancé une attaque par force brute contre certains comptes d’utilisateurs de Dashlane », explique l’entreprise. L’attaquant essayait de casser l’authentification à deux facteurs afin d’enregistrer de nouveaux appareils sur des comptes d’utilisateurs, pour ensuite accéder aux données.

Bien évidemment, des protections ont permis de limiter l’attaque – mais pas de la bloquer totalement : « En raison du nombre élevé de tentatives d’accès aux comptes utilisateurs, les contrôles de sécurité de Dashlane ont automatiquement verrouillé les comptes ciblés par l’attaque », explique Dashlane.

Des comptes ont été suspendus de manière temporaire, mais surtout pour une vingtaine de clients le coffre-fort a été dérobé. Ils ont tous été déjà contactés individuellement par Dashlane.

Quels sont les risques ?

Avec les coffres-forts chiffrés, le ou les pirates ne peuvent pas faire grand-chose, sauf à réussir à les ouvrir évidemment. Ils accéderaient alors à l’intégralité des informations qu’ils contiennent : mots de passe, identifiants… une vraie caverne d’Alibaba.

Pour arriver à leurs fins, ils peuvent tenter de faire du phishing afin que vous « donniez » involontairement votre mot de passe maître, mais aussi tenter de passer en force.

Brutale, cette méthode consiste à tester toutes les combinaisons possibles jusqu’à trouver la bonne. En théorie, cela finit toujours par fonctionner. En pratique, il faut un temps quasi infini selon la taille et la complexité de votre mot de passe. On parle aussi d’entropie.

Autant dire que si votre mot de passe est « password123 », il ne tiendra même pas quelques secondes. Avec une copie de votre coffre-fort en sa possession, un pirate peut effectuer autant de tentatives qu’il le souhaite jusqu’à réussir à trouver le bon mot de passe et ainsi percer les protections.

Des années plus tard, la fuite Lastpass fait toujours des victimes

La fuite de Lastpass fin 2022 en est un parfait exemple. Cette fuite avait encore des conséquences en 2025, comme le rapporte BleepingComputer : « Plutôt que le portefeuille [de cryptomonnaie, qui est aussi parfois stocké dans les coffres-forts, ndlr] soit vidé immédiatement après une brèche, les vols se sont multipliés par vagues des mois ou des années plus tard, illustrant comment les attaquants décryptaient progressivement les coffres ».

Une autre manière de le dire : si votre coffre-fort est dans la nature, il est plus que recommandé de changer l’intégralité des secrets et mots de passe qui y sont enregistrés. Un pirate pourrait en forcer la porte maintenant comme dans quelques années quand la puissance de calcul coutera bien moins chère, par exemple.

Votre mot de passe maître doit être fort et robuste !

Dashlane reconnait ne pas avoir « d’exigences spécifiques pour les mots de passe maîtres », mais précise néanmoins s’appuyer sur « l’algorithme zxcvbn [de Daniel Lowe Wheeler chez Dropbox, ndlr] afin d’évaluer la sécurité de votre mot de passe lors de sa création ». L’entreprise prodigue aussi quelques conseils. Next a aussi des dossiers sur le sujet.

• Choisir un bon mot de passe : les règles à connaître, les pièges à éviter
• Phrases de passe : l’ANSSI passe en mode 2.0

Les clients de Dashlane sont les victimes, mais cette affaire rappelle l’importance du mot de passe maître qui sera le dernier rempart en cas de fuite de données. C’est valable quel que soit le gestionnaire utilisé, y compris (et surtout) en autohébergé. Si vous autohébergez un gestionnaire, ne sous-estimez surtout pas le mot de passe maitre.

• [Tuto] Auto-héberger son gestionnaire de mots de passe avec Vaultwarden (Bitwarden)
• #Nextpresso : on installe Vaultwarden sur une VM gratuite Google et Oracle… ça marche ?

Hard times

Une importante faille de sécurité a été découverte dans Linux par un ingénieur en sécurité de chez SpaceX. Exploitée, elle permet d’obtenir les droits root sur un compte local. Elle résidait dans le noyau depuis 2007.

La faille CIFSwitch fait parler d’elle depuis quelques jours. Découverte par Asim Viladi Oglu Manizada, ingénieur en sécurité chez SpaceX, elle a fait l’objet d’un billet détaillé par ce dernier le 27 mai. On peut notamment y lire qu’elle a été introduite en 2007 et réside à l’intersection du module CIFS (Common Internet File System) dans le noyau et d’un code en espace utilisateur.

Une absence de vérification

L’ingénieur explique que CIFS/SMB est un protocole de fichiers réseau de type Windows et est utilisé pour le montage de ressources distantes. La partie dans le noyau sert ainsi à monter le partage, communiquer avec le serveur, gérer les lectures et écritures, etc. Dans le cas de ressources protégées par Kerberos, le composant noyau fait cependant appel à un assistant (helper) en espace utilisateur fourni par cifs-utils.

C’est là que survient le problème. Quand un partage réseau nécessite une authentification Kerberos, le noyau demande une clé de type cifs.spnego. À ce moment, un composant disposant des droits root, cifs.upcall, est chargé de récupérer les informations d’identification pour que la requête d’une clé se poursuive. Malheureusement, rien n’empêche un utilisateur malintentionné et sans privilège de lancer la même requête avec des informations fabriquées de toutes pièces.

La fausse description peut ainsi introduire un identifiant PID contrôlé par le pirate. Or, le mécanisme de fourniture de la clé ne rejette pas les descriptions fournies par du code en espace utilisateur : elles sont traitées comme si elles venaient du noyau. Résultat, une belle faille de sécurité de type élévation de privilèges. Estampillée CVE-2026-46243, elle échappe de justesse à la qualification « critique » avec un score CVSS de 7,8.

Une dangerosité variable

Sa dangerosité réelle est difficile à exprimer, car elle dépend fortement des configurations. Il faut ainsi un noyau vulnérable, une version vulnérable de cifs-utils, ainsi que, au choix, un espace de noms utilisateur non privilégié ou une politique SELinux/AppArmor ne bloquant pas l’attaque.

Sur les distributions Ubuntu 18.04 à 24.04, Debian 11 à 13, openSUSE Leap 15.6 ou Oracle Linux 8 ou 9 notamment, si cifs-utils est installé, la configuration est vulnérable par défaut. Pour d’autres, comme Linux Mint (21.3 / 22.3), CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux (versions 2021.4 à 2026.1) et SUSE Linux Enterprise Server 15 SP7, cifs-utils est installé par défaut, rendant ces distributions vulnérables.

Les correctifs sont en cours de distribution ou le seront très prochainement. Indépendamment du correctif, il est recommandé de vérifier si le protocole CIFS/SMB est installé et, s’il ne sert pas, de le supprimer. Cela fait plusieurs fois en quelques semaines que des failles d’élévation de privilèges sont détectées dans Linux.

• Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root

Hard times

Une importante faille de sécurité a été découverte dans Linux par un ingénieur en sécurité de chez SpaceX. Exploitée, elle permet d’obtenir les droits root sur un compte local. Elle résidait dans le noyau depuis 2007.

La faille CIFSwitch fait parler d’elle depuis quelques jours. Découverte par Asim Viladi Oglu Manizada, ingénieur en sécurité chez SpaceX, elle a fait l’objet d’un billet détaillé par ce dernier le 27 mai. On peut notamment y lire qu’elle a été introduite en 2007 et réside à l’intersection du module CIFS (Common Internet File System) dans le noyau et d’un code en espace utilisateur.

Une absence de vérification

L’ingénieur explique que CIFS/SMB est un protocole de fichiers réseau de type Windows et est utilisé pour le montage de ressources distantes. La partie dans le noyau sert ainsi à monter le partage, communiquer avec le serveur, gérer les lectures et écritures, etc. Dans le cas de ressources protégées par Kerberos, le composant noyau fait cependant appel à un assistant (helper) en espace utilisateur fourni par cifs-utils.

C’est là que survient le problème. Quand un partage réseau nécessite une authentification Kerberos, le noyau demande une clé de type cifs.spnego. À ce moment, un composant disposant des droits root, cifs.upcall, est chargé de récupérer les informations d’identification pour que la requête d’une clé se poursuive. Malheureusement, rien n’empêche un utilisateur malintentionné et sans privilège de lancer la même requête avec des informations fabriquées de toutes pièces.

La fausse description peut ainsi introduire un identifiant PID contrôlé par le pirate. Or, le mécanisme de fourniture de la clé ne rejette pas les descriptions fournies par du code en espace utilisateur : elles sont traitées comme si elles venaient du noyau. Résultat, une belle faille de sécurité de type élévation de privilèges. Estampillée CVE-2026-46243, elle échappe de justesse à la qualification « critique » avec un score CVSS de 7,8.

Une dangerosité variable

Sa dangerosité réelle est difficile à exprimer, car elle dépend fortement des configurations. Il faut ainsi un noyau vulnérable, une version vulnérable de cifs-utils, ainsi que, au choix, un espace de noms utilisateur non privilégié ou une politique SELinux/AppArmor ne bloquant pas l’attaque.

Sur les distributions Ubuntu 18.04 à 24.04, Debian 11 à 13, openSUSE Leap 15.6 ou Oracle Linux 8 ou 9 notamment, si cifs-utils est installé, la configuration est vulnérable par défaut. Pour d’autres, comme Linux Mint (21.3 / 22.3), CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux (versions 2021.4 à 2026.1) et SUSE Linux Enterprise Server 15 SP7, cifs-utils est installé par défaut, rendant ces distributions vulnérables.

Les correctifs sont en cours de distribution ou le seront très prochainement. Indépendamment du correctif, il est recommandé de vérifier si le protocole CIFS/SMB est installé et, s’il ne sert pas, de le supprimer. Cela fait plusieurs fois en quelques semaines que des failles d’élévation de privilèges sont détectées dans Linux.

• Copy fail : depuis 2017, une faille dans le noyau Linux permettait à un utilisateur de passer root

L’assistance IA mise en place par Meta pour la gestion des comptes Instagram a autorisé pendant plusieurs semaines n’importe qui d’assez malin à changer l’adresse e-mail associée à un compte. Les propriétaires légitimes se retrouvaient donc « enfermés dehors », incapables de se connecter à leur compte et de reprendre la main.

Depuis le mois de mars, les utilisateurs de Facebook et d’Instagram qui ont besoin d’aide pour gérer leur compte peuvent faire appel à un assistant IA spécialisé, « fiable, rapide, efficace, disponible en tout temps », promettait Meta. Un soutien « axé sur l’action » pour résoudre les problèmes de compte « de A à Z ». Ce qui signifie réaliser des opérations particulièrement sensibles comme la réinitialisation du mot de passe ou le changement de l’e-mail associé au compte.

Depuis la mise en place de ce nouveau mécanisme IA, plusieurs profils Instagram de premier plan, comme un compte appartenant à Barack Obama, celui de la marque Sephora ou du chef des sous-officiers de la Space Force, ont été piratés ces dernières semaines. Les propriétaires légitimes de ces comptes ne pouvaient plus y accéder et pour cause, l’adresse e-mail associée avait changé sans leur autorisation.

Le « nouveau » propriétaire du compte était alors en mesure de publier n’importe quel contenu, contacter les abonnés, diffuser des arnaques, revendre le compte à des tiers… 404media rapporte que Meta aurait corrigé la vulnérabilité qui ouvrait la porte à ces margoulins. C’est la méthode qui est intéressante ici : il ne s’agit pas d’une faille de sécurité à proprement parler, mais d’ingénierie sociale appliquée aux agents IA.

Sur Telegram, des chercheurs en sécurité et des groupes de hackers ont partagé des vidéos et des captures d’écran explicitant le mode opératoire pour voler un compte Instagram. Le scénario est le suivant : l’attaquant connaît le nom d’utilisateur Instagram de la cible ; armé d’un VPN, qui lui permet d’apparaître dans le même pays ou la même région que la victime, il lance une procédure de récupération de compte.

Après avoir ouvert une conversation avec l’assistant IA de Meta, le pirate convainc le bot de remplacer l’adresse e-mail associée au compte par une adresse qu’il contrôle. L’IA envoie alors un code de validation à cette nouvelle adresse. Une fois l’adresse modifiée, l’attaquant peut demander une réinitialisation du mot de passe et prendre le contrôle du compte.

L’IA de Meta aurait accepté une opération extrêmement sensible sans vérifier correctement que l’utilisateur était bien le propriétaire du compte. Cette technique d’injection de prompts contourne les sécurités habituelles liées à un changement d’adresse e-mail, une opération qui ne peut normalement pas être effectuée sans une authentification forte et un délai ou une validation depuis l’ancienne adresse. L’assistance de Meta bénéficiait donc manifestement de privilèges extrêmement élevés, sans qu’aucun garde-fou ne vienne mettre le holà.

En décembre dernier, OpenAI abordait les injections de prompts sur le fond, et admettait qu’il s’agissait d’un problème à long terme. Meta n’est pas le seul acteur IA à y faire face.

• OpenAI : les injections de prompts resteront « un défi pour de nombreuses années »