Quand une faille critique est exploitée activement, attendre le prochain cycle de mises à jour n'est plus une option. Voici comment l'urgence redéfinit les règles du jeu en cybersécurité.

• lien nᵒ 1 : Dépôt GitHub
• lien nᵒ 2 : Documentation officielle de Dark Moon
• lien nᵒ 3 : Vidéo de démonstration de Dark Moon sur Juice Shop
• lien nᵒ 4 : Site officiel de Dark Moon

git clone https://github.com/ASCIT31/Dark-Moon.git
cd Dark-Moon
chmod +x install.sh darkmoon.sh
./install.sh

./darkmoon.sh

./darkmoon.sh "TARGET: http://172.19.0.3:3000"

./darkmoon.sh "TARGET: http://172.19.0.3:3000"

./darkmoon.sh "TARGET: https://app.example.org PROGRAM='Audit interne' TARGETS=*.example.org,API:https://api.example.org OUT=payments.example.org,10.0.0.0/8 FOCUS=sqli,rce,ssrf,idor EXCLUDE=brute-force NOISE=moderate FORMAT=standard RULES='POC only;no real user data'"

./darkmoon.sh --log <session_id>

Commentaires : voir le flux Atom ouvrir dans le navigateur

Critique local

Une faille de sécurité a été détectée dans les anciennes puces A12 et A13. Liée à l’architecture matérielle, elle ne peut pas être corrigée par une simple mise à jour logicielle, car elle s’appuie sur un bug dans le contrôleur USB.

La société européenne de cybersécurité Paradigm Shift a publié les détails d’une faille dans le BootROM (aussi appelé SecureROM) des puces Apple A12 et A13, accompagnée d’un exploit fonctionnel nommé « usbliter8 », rapporte MacRumors.

Le BootROM est le premier code exécuté par un iPhone à sa mise sous tension. Une vulnérabilité dans ce composant ne peut pas être corrigée par une mise à jour logicielle, car il est gravé directement dans la puce. Si ce type de faille vous rappelle des souvenirs, c’est qu’elle appartient à la même famille que checkm8, une faille matérielle rendue publique en 2019 et qui touchait déjà tous les iPhone du 4S au X.

Où réside la faille ?

La faille se trouve plus précisément dans le contrôleur USB des puces A12 et A13 (et dans une moindre mesure les puces S4 et S5 des Apple Watch). Lorsqu’un iPhone reçoit des données USB au démarrage, le contrôleur utilise un tampon mémoire (buffer) pour stocker les paquets entrants.

Paradigm Shift a découvert qu’en envoyant une séquence spécifique de paquets anormalement petits, il était possible de manipuler un pointeur matériel interne de façon à le faire « reculer » dans la mémoire, permettant l’écriture de données à des emplacements qu’il ne devrait jamais atteindre.

Les chercheurs précisent qu’il s’agit apparemment d’un bug du contrôleur USB matériel lui-même, et non du logiciel d’Apple, expliquant pourquoi aucun patch logiciel ne peut le corriger.

Grave à quel point ?

Seuls deux modèles de smartphones Apple sont touchés par cette faille : les iPhone XS et 11. La puce A11, qui équipait l’iPhone X, n’est pas touchée par cette « nouvelle » faille car son pilote USB réinitialise manuellement le pointeur après chaque paquet stocké dans le tampon. Les puces A14 et suivantes sont protégées car elles configurent correctement une fonctionnalité de protection mémoire au niveau du BootROM. Les A12 et A13 se retrouvent ainsi dans une zone intermédiaire vulnérable.

Selon la puce concernée, le niveau de difficulté diffère largement. Sur les appareils A12, obtenir l’exécution de code est relativement simple. Sur les appareils A13 en revanche, c’est beaucoup plus difficile car Apple a introduit le Pointer Authentication Code (PAC), qui détecte et bloque certains types de falsification de mémoire. Paradigm Shift indique qu’un processus complexe en plusieurs étapes a été nécessaire pour contourner le PAC sur l’A13 avant d’obtenir le contrôle du processeur.

Une fois le contrôle obtenu, l’exploit installe un gestionnaire personnalisé qui survit à un redémarrage de l’appareil et ajoute deux capacités : abaisser temporairement les paramètres de sécurité de l’appareil et lancer un logiciel non signé sans aucune vérification. Il injecte également la chaîne traditionnelle « PWND » dans le numéro de série USB de l’iPhone, signal de compromission qui reprend une convention héritée de checkm8.

Il s’agit d’une procédure locale, qui requiert une connexion USB et donc un accès physique. Elle ne peut pas être exploitée à distance, mais est quand même considérée comme critique par les chercheurs, car rien ne peut la corriger.

Un bug dans la correction

L’ironie veut que la nouvelle faille soit exploitable à cause des corrections apportées par Apple au mécanisme qui permettait à checkm8 de fonctionner en 2019. Cette correction a introduit un nouveau bug, qui permet aujourd’hui à usbliter8 de fonctionner, alors que l’iPhone X (puce A11) y est insensible par exemple.

Le bug et son exploitation peuvent-ils affecter la Secure Enclave des puces Apple, responsable (entre autres) du stockage des clés de sécurité ? Pas directement selon les chercheurs de Paradigm Shift. Une telle compromission du BootROM ouvre toutefois de nouvelles voies d’attaques contre ce composant crucial.

L’entreprise de sécurité indique dans son billet avoir averti Apple de ces problèmes avant la publication des résultats. Paradigm Shift affirme qu’il s’agit d’une divulgation coordonnée, en accord avec la firme de Cupertino.

Critique local

Une faille de sécurité a été détectée dans les anciennes puces A12 et A13. Liée à l’architecture matérielle, elle ne peut pas être corrigée par une simple mise à jour logicielle, car elle s’appuie sur un bug dans le contrôleur USB.

La société européenne de cybersécurité Paradigm Shift a publié les détails d’une faille dans le BootROM (aussi appelé SecureROM) des puces Apple A12 et A13, accompagnée d’un exploit fonctionnel nommé « usbliter8 », rapporte MacRumors.

Le BootROM est le premier code exécuté par un iPhone à sa mise sous tension. Une vulnérabilité dans ce composant ne peut pas être corrigée par une mise à jour logicielle, car il est gravé directement dans la puce. Si ce type de faille vous rappelle des souvenirs, c’est qu’elle appartient à la même famille que checkm8, une faille matérielle rendue publique en 2019 et qui touchait déjà tous les iPhone du 4S au X.

Où réside la faille ?

La faille se trouve plus précisément dans le contrôleur USB des puces A12 et A13 (et dans une moindre mesure les puces S4 et S5 des Apple Watch). Lorsqu’un iPhone reçoit des données USB au démarrage, le contrôleur utilise un tampon mémoire (buffer) pour stocker les paquets entrants.

Paradigm Shift a découvert qu’en envoyant une séquence spécifique de paquets anormalement petits, il était possible de manipuler un pointeur matériel interne de façon à le faire « reculer » dans la mémoire, permettant l’écriture de données à des emplacements qu’il ne devrait jamais atteindre.

Les chercheurs précisent qu’il s’agit apparemment d’un bug du contrôleur USB matériel lui-même, et non du logiciel d’Apple, expliquant pourquoi aucun patch logiciel ne peut le corriger.

Grave à quel point ?

Seuls deux modèles de smartphones Apple sont touchés par cette faille : les iPhone XS et 11. La puce A11, qui équipait l’iPhone X, n’est pas touchée par cette « nouvelle » faille car son pilote USB réinitialise manuellement le pointeur après chaque paquet stocké dans le tampon. Les puces A14 et suivantes sont protégées car elles configurent correctement une fonctionnalité de protection mémoire au niveau du BootROM. Les A12 et A13 se retrouvent ainsi dans une zone intermédiaire vulnérable.

Selon la puce concernée, le niveau de difficulté diffère largement. Sur les appareils A12, obtenir l’exécution de code est relativement simple. Sur les appareils A13 en revanche, c’est beaucoup plus difficile car Apple a introduit le Pointer Authentication Code (PAC), qui détecte et bloque certains types de falsification de mémoire. Paradigm Shift indique qu’un processus complexe en plusieurs étapes a été nécessaire pour contourner le PAC sur l’A13 avant d’obtenir le contrôle du processeur.

Une fois le contrôle obtenu, l’exploit installe un gestionnaire personnalisé qui survit à un redémarrage de l’appareil et ajoute deux capacités : abaisser temporairement les paramètres de sécurité de l’appareil et lancer un logiciel non signé sans aucune vérification. Il injecte également la chaîne traditionnelle « PWND » dans le numéro de série USB de l’iPhone, signal de compromission qui reprend une convention héritée de checkm8.

Il s’agit d’une procédure locale, qui requiert une connexion USB et donc un accès physique. Elle ne peut pas être exploitée à distance, mais est quand même considérée comme critique par les chercheurs, car rien ne peut la corriger.

Un bug dans la correction

L’ironie veut que la nouvelle faille soit exploitable à cause des corrections apportées par Apple au mécanisme qui permettait à checkm8 de fonctionner en 2019. Cette correction a introduit un nouveau bug, qui permet aujourd’hui à usbliter8 de fonctionner, alors que l’iPhone X (puce A11) y est insensible par exemple.

Le bug et son exploitation peuvent-ils affecter la Secure Enclave des puces Apple, responsable (entre autres) du stockage des clés de sécurité ? Pas directement selon les chercheurs de Paradigm Shift. Une telle compromission du BootROM ouvre toutefois de nouvelles voies d’attaques contre ce composant crucial.

L’entreprise de sécurité indique dans son billet avoir averti Apple de ces problèmes avant la publication des résultats. Paradigm Shift affirme qu’il s’agit d’une divulgation coordonnée, en accord avec la firme de Cupertino.

Une enquête de journalistes a mis au jour un vaste marché noir qui détourne des batteries usagées de voitures électriques pour les greffer illégalement sur des deux-roues. Ce qui n’est pas sans conséquence sur la sécurité des véhicules.

Prudence est mère de sûreté

Plusieurs certificats de sécurité utilisés par Microsoft et Linux pour Secure Boot arriveront à échéance cette année, dont une première vague le 27 juin. Nous faisons le point sur la situation, plus simple qu’il n’y paraît. Du moins si tout se passe bien.

Pour comprendre la situation, nous devons rappeler quelques points. Secure Boot est une fonctionnalité de sécurité du firmware UEFI dont l’objectif est d’empêcher l’exécution de code malveillant avant même que le système d’exploitation démarre, c’est-à-dire à un stade où les antivirus et autres protections logicielles classiques n’ont aucune visibilité. Les bootkits sont ainsi particulièrement dangereux, car ils s’exécutent avec un niveau de privilège supérieur à celui du système et survivent à une réinstallation complète de Windows ou Linux.

Le fonctionnement repose sur une chaîne de confiance cryptographique hiérarchisée :

1. La PK (Platform Key), détenue par le fabricant de la carte mère ou du PC et qui contrôle l’accès au niveau inférieur
2. La KEK (Key Exchange Key), utilisée pour mettre à jour les bases de signatures
3. La DB (Signature Database), qui liste les certificats de confiance autorisant tel ou tel bootloader à s’exécuter
4. La DBX (base de révocation), liste noire des signatures compromises qui bloque l’exécution de bootloaders connus comme vulnérables, même quand ils possèdent une signature valide

Pendant le démarrage, le bootloader vérifie chaque maillon de la chaine l’un après l’autre en comparant leur signature à celles présentes dans les bases mentionnées. Si l’une de ces signatures ne correspond pas ou fait partie de la liste de révocation, le firmware refuse le chargement du composant lié et interrompt le démarrage.

L’origine du problème

En 2011, Microsoft a établi trois certificats centraux : la Microsoft Corporation KEK CA 2011 pour la base KEK, la Microsoft Windows Production PCA 2011 pour les composants Windows signés, et la Microsoft Corporation UEFI CA 2011 pour les logiciels tiers, comme le rappelait Security Today en avril et Ars Technica le 17 juin.

Ces certificats disposaient d’une validité de 15 ans. Chacun a sa date d’expiration : les deux certificats Corporation (KEK et UEFI) expirent respectivement les 24 et 27 juin, le certificat Production court jusqu’au 19 octobre. Deux certificats vont donc expirer dans quelques jours, tandis que l’autre aura lieu dans quatre mois. Or, cette clé UEFI CA 2011, qui expire le 27 juin, est aussi utilisée pour la signature des bootloaders tiers, dont le « shim » de Linux, que les distributions peuvent utiliser pour se rendre compatibles avec Secure Boot.

Nous non plus, on n’aime pas trop se comparer à Palantir…

L’actualité est chargée autour de ChapsVision, une société française spécialisée dans l’analyse et la surveillance. En plus de prendre la place de Palantir à la DGSI, elle vient de signer un partenariat avec Scaleway. Nous avons échangé avec plusieurs membres de l’équipe de ChapsVision (dont le directeur général Silvano Sansoni) sur les projets en cours, sa plateforme, ses ambitions.

ChapsVision migre chez Scaleway (en cours de qualification SecNumCloud)

Pour le premier jour du salon Vivatech à Paris, Scaleway et ChapsVision annoncent un partenariat. Dans les faits, il s’agit pour ChapsVision de migrer dans les datacenters de l’hébergeur français. Les détails financiers du contrat ne sont pas précisés, tout juste savons nous que Scaleway sera à terme le seul hébergeur de ChapsVision (serveurs, stockage, puissance de calcul…).

La ministre déléguée en charge de l’IA et du Numérique s’est félicitée de cet accord durant une conférence de presse sur le stand de Scaleway, rappelant que Scaleway était aussi la nouvelle plateforme d’hébergement des données de santé, à la place de Microsoft.

• Scaleway remporte l’hébergement des données de santé à la place de Microsoft

« C’est la situation que je considère comme idéale. C’est de la souveraineté avec deux acteurs français et sécurisés, notamment avec Scaleway qui est SecNumCloud »… mais ce n’est pas (encore) le cas, l’entreprise figurant toujours dans la liste des prestataires en cours de qualification selon le site de l’ANSSI.

Scaleway a, pour rappel, validé le jalon J0 en janvier 2025, mais n’a pas obtenu le sésame de l’ANSSI pour le moment, comme nous confirme Damien Lucas, le CEO de Scaleway. Une annonce « visionnaire » de la ministre ? Réponse dans les semaines ou mois à venir.

Palantir + ChapsVision à la DGSI ? Oui, le « temps de faire la transition »

Nous profitions d’avoir ChapsVision sous la main pour revenir sur le contrat remporté avec la DGSI, comme vient de l’annoncer Sébastien Lecornu, pour prendre la place de Palantir : « On a gagné le lot deux du projet Outil de traitement des données hétérogènes (OTDH). L’appel d’offres a commencé il y a cinq ans, on avait gagné le lot un l’année dernière ».

Et ça marche toujours aussi bien

Une campagne de phishing est en cours pour obtenir des jetons d’authentification Microsoft 365 ; prévient le FBI. La technique n’est pas nouvelle dans l’absolu, mais cette campagne s’appuie sur la plateforme Kali365 de « phishing-as-a-service », permettant une forte automatisation du processus.

En matière de sécurité, les experts sont unanimes : l’authentification multifacteur apporte une vraie couche de protection supplémentaire. Elle permet, dans sa forme la plus classique, de lier deux facteurs : une information mémorisée et une autre fournie par un équipement. Traditionnellement, il s’agit d’un mot de passe et d’une donnée délivrée par le smartphone, comme un code à six chiffres ou, plus directement, un jeton d’authentification.

Bien que globalement efficace, cette protection n’est pas inviolable. Même si on le savait, l’alerte dressée par le FBI fournit un brusque rappel.

Vol de jetons automatisé

Le FBI a émis un avertissement public concernant une plateforme de phishing-as-a-service nommée Kali365, repérée pour la première fois en avril 2026 et diffusée principalement via Telegram. Cette plateforme permet aux cybercriminels d’obtenir des jetons d’accès Microsoft 365 et de contourner l’authentification multifacteur (MFA) sans même intercepter les identifiants des utilisateurs. Bien que l’avertissement date du 21 mai, la campagne est toujours en cours.

La technique utilisée s’appelle le « device code phishing ». L’attaque commence par un email malveillant qui imite un service de cloud ou de partage de documents bien connu. Il contient un code d’appareil accompagné d’instructions pour se rendre sur une page de vérification Microsoft authentique et y saisir ce code

Si la victime valide ce code, elle autorise sans le savoir l’appareil de l’attaque à accéder à son compte. L’accès obtenu grâce à la capture du jeton (OAuth) est persistant, le pirate ayant alors une connexion constante aux services liés, dont Outlook, Teams et OneDrive. La validation de cet accès permet au pirate de ne plus avoir besoin du mot de passe, ni de repasser par un autre facteur. Du moins si la configuration du compte est celle par défaut, car d’autres mécanismes peuvent se greffer ou modifier ce flux en entreprise.

Redoutable

Selon plusieurs entreprises spécialisées dans la sécurité, dont BitDefender, la technique est redoutable : puisqu’il s’agit du détournement d’un service authentique existant, « il n’y a pas de faux site à repérer, ni de nom de domaine mal orthographié. Le jeton volé unique peut débloquer d’autres applications cloud, transformant potentiellement un clic négligent en un incident de sécurité à grande portée ».

Comme on a pu le voir par le passé, la technique n’est pas nouvelle. Mais elle demandait jusqu’à présent certains efforts dans la mise en place de serveurs spécifiques, la création de sites mimant les pages de Microsoft et la diffusion des emails de phishing. C’est là qu’intervient la plateforme Kali365 qui permet, pour environ 250 dollars par mois (ou 2 000 dollars par an), de générer par IA des leurres efficaces. Cette « suite » donne également accès à des tableaux de bord pour suivre les campagnes en cours et des modèles automatisés pour lancer des attaques.

• Une vaste campagne de phishing contre des clients Microsoft 365 contourne l’authentification multifacteurs
• De fausses applications Microsoft 365 pour voler des jetons d’authentification

Kali365 semble être apparue en avril, ce que confirme également le FBI. BitDefender, qui avait relevé son existence, indiquait alors que durant ce seul mois, des centaines d’attaques avaient été repérées en Amérique du Nord et en Europe.

« Grâce à l’abonnement à la plateforme Kali365, les cyber-acteurs peuvent capturer des jetons « OAuth » et obtenir un accès permanent aux environnements Microsoft 365 des individus ou entités ciblés. Kali365 abaisse la barrière d’entrée, offrant aux attaquants moins techniques un accès à des appâts de phishing générés par l’IA, des modèles de campagnes automatisés, des tableaux de bord ciblés en temps réel pour le suivi individuel et des entités, ainsi que des capacités de capture de tokens OAuth », résume ainsi le FBI.

Que faire ?

Les conseils donnés par le Bureau ou les entreprises de sécurité sont sans surprise dans ce contexte. En priorité, mettre en place une politique d’accès conditionnel dans les entreprises, c’est-à-dire définir précisément quel type d’appareil a le droit de se connecter au réseau. En instaurant ce type d’accès, on bloque le flux d’appareils, avec d’éventuelles exceptions pour certains cas très précis, comme pour les applications et processus métier.

Il est également conseillé d’auditer le flux des jetons émis pour identifier les dépendances légitimes, de bloquer les politiques de transfert d’authentification et d’exclure les comptes d’accès d’urgence si l’utilisation des codes ne peut pas être restreinte. En outre, remplacer le deuxième facteur par un moyen ne pouvant faire l’objet d’un vol par phishing, comme les clés matérielles, rend caduc ce type d’opération.

Il s’agit cependant de conseils pour les entreprises. Même si le grand public est moins souvent visé, l’automatisation des attaques peut faire basculer la pratique. Les conseils sont alors moins spécifiques, le premier d’entre eux étant toujours de vérifier soigneusement le domaine de l’expéditeur et les liens dans l’email. L’examen des mots et phrases peut également renseigner sur le sérieux du contenu. L’utilisation de suites de sécurité peut également aider.

Interrogée par The Hill le 15 juin, Microsoft indique simplement qu’il est recommandé de suivre les conseils du FBI. Le porte-parole ajoute que l’entreprise avait déjà fait tomber plusieurs réseaux de ce type, dont Raccoon365. « Plus largement, Microsoft œuvre activement à perturber les écosystèmes cybercriminels derrière le phishing en tant que service et les activités de prise de contrôle de comptes afin de protéger nos clients », déclare-t-il.

L’authentification multifacteurs en elle-même n’est pas remise en question. Il faut simplement se rappeler qu’il s’agit d’une protection supplémentaire et qu’une faille humaine est toujours possible.

Et ça marche toujours aussi bien

Une campagne de phishing est en cours pour obtenir des jetons d’authentification Microsoft 365 ; prévient le FBI. La technique n’est pas nouvelle dans l’absolu, mais cette campagne s’appuie sur la plateforme Kali365 de « phishing-as-a-service », permettant une forte automatisation du processus.

En matière de sécurité, les experts sont unanimes : l’authentification multifacteur apporte une vraie couche de protection supplémentaire. Elle permet, dans sa forme la plus classique, de lier deux facteurs : une information mémorisée et une autre fournie par un équipement. Traditionnellement, il s’agit d’un mot de passe et d’une donnée délivrée par le smartphone, comme un code à six chiffres ou, plus directement, un jeton d’authentification.

Bien que globalement efficace, cette protection n’est pas inviolable. Même si on le savait, l’alerte dressée par le FBI fournit un brusque rappel.

Vol de jetons automatisé

Le FBI a émis un avertissement public concernant une plateforme de phishing-as-a-service nommée Kali365, repérée pour la première fois en avril 2026 et diffusée principalement via Telegram. Cette plateforme permet aux cybercriminels d’obtenir des jetons d’accès Microsoft 365 et de contourner l’authentification multifacteur (MFA) sans même intercepter les identifiants des utilisateurs. Bien que l’avertissement date du 21 mai, la campagne est toujours en cours.

La technique utilisée s’appelle le « device code phishing ». L’attaque commence par un email malveillant qui imite un service de cloud ou de partage de documents bien connu. Il contient un code d’appareil accompagné d’instructions pour se rendre sur une page de vérification Microsoft authentique et y saisir ce code

Si la victime valide ce code, elle autorise sans le savoir l’appareil de l’attaque à accéder à son compte. L’accès obtenu grâce à la capture du jeton (OAuth) est persistant, le pirate ayant alors une connexion constante aux services liés, dont Outlook, Teams et OneDrive. La validation de cet accès permet au pirate de ne plus avoir besoin du mot de passe, ni de repasser par un autre facteur. Du moins si la configuration du compte est celle par défaut, car d’autres mécanismes peuvent se greffer ou modifier ce flux en entreprise.

Redoutable

Selon plusieurs entreprises spécialisées dans la sécurité, dont BitDefender, la technique est redoutable : puisqu’il s’agit du détournement d’un service authentique existant, « il n’y a pas de faux site à repérer, ni de nom de domaine mal orthographié. Le jeton volé unique peut débloquer d’autres applications cloud, transformant potentiellement un clic négligent en un incident de sécurité à grande portée ».

Comme on a pu le voir par le passé, la technique n’est pas nouvelle. Mais elle demandait jusqu’à présent certains efforts dans la mise en place de serveurs spécifiques, la création de sites mimant les pages de Microsoft et la diffusion des emails de phishing. C’est là qu’intervient la plateforme Kali365 qui permet, pour environ 250 dollars par mois (ou 2 000 dollars par an), de générer par IA des leurres efficaces. Cette « suite » donne également accès à des tableaux de bord pour suivre les campagnes en cours et des modèles automatisés pour lancer des attaques.

• Une vaste campagne de phishing contre des clients Microsoft 365 contourne l’authentification multifacteurs
• De fausses applications Microsoft 365 pour voler des jetons d’authentification

Kali365 semble être apparue en avril, ce que confirme également le FBI. BitDefender, qui avait relevé son existence, indiquait alors que durant ce seul mois, des centaines d’attaques avaient été repérées en Amérique du Nord et en Europe.

« Grâce à l’abonnement à la plateforme Kali365, les cyber-acteurs peuvent capturer des jetons « OAuth » et obtenir un accès permanent aux environnements Microsoft 365 des individus ou entités ciblés. Kali365 abaisse la barrière d’entrée, offrant aux attaquants moins techniques un accès à des appâts de phishing générés par l’IA, des modèles de campagnes automatisés, des tableaux de bord ciblés en temps réel pour le suivi individuel et des entités, ainsi que des capacités de capture de tokens OAuth », résume ainsi le FBI.

Que faire ?

Les conseils donnés par le Bureau ou les entreprises de sécurité sont sans surprise dans ce contexte. En priorité, mettre en place une politique d’accès conditionnel dans les entreprises, c’est-à-dire définir précisément quel type d’appareil a le droit de se connecter au réseau. En instaurant ce type d’accès, on bloque le flux d’appareils, avec d’éventuelles exceptions pour certains cas très précis, comme pour les applications et processus métier.

Il est également conseillé d’auditer le flux des jetons émis pour identifier les dépendances légitimes, de bloquer les politiques de transfert d’authentification et d’exclure les comptes d’accès d’urgence si l’utilisation des codes ne peut pas être restreinte. En outre, remplacer le deuxième facteur par un moyen ne pouvant faire l’objet d’un vol par phishing, comme les clés matérielles, rend caduc ce type d’opération.

Il s’agit cependant de conseils pour les entreprises. Même si le grand public est moins souvent visé, l’automatisation des attaques peut faire basculer la pratique. Les conseils sont alors moins spécifiques, le premier d’entre eux étant toujours de vérifier soigneusement le domaine de l’expéditeur et les liens dans l’email. L’examen des mots et phrases peut également renseigner sur le sérieux du contenu. L’utilisation de suites de sécurité peut également aider.

Interrogée par The Hill le 15 juin, Microsoft indique simplement qu’il est recommandé de suivre les conseils du FBI. Le porte-parole ajoute que l’entreprise avait déjà fait tomber plusieurs réseaux de ce type, dont Raccoon365. « Plus largement, Microsoft œuvre activement à perturber les écosystèmes cybercriminels derrière le phishing en tant que service et les activités de prise de contrôle de comptes afin de protéger nos clients », déclare-t-il.

L’authentification multifacteurs en elle-même n’est pas remise en question. Il faut simplement se rappeler qu’il s’agit d’une protection supplémentaire et qu’une faille humaine est toujours possible.

À leurs actes manqués

Alors que la transposition de NIS2 était prévue avant la fin de l’été, ce ne sera finalement pas le cas. Les députés sont certes convoqués pour une session extraordinaire, mais NIS2 n’est pas au programme de la trentaine de projets de loi qui va être examinée.

Date limite : octobre 2024

17 octobre 2024 : c’était la date limite pour transposer le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, plus connu sous le nom NIS2. Vincent Strubel (patron de l’ANSSI) avait déjà prévenu début 2024 : « le 17 octobre, il ne va pas se passer grand-chose de spécial, en tout cas dans le domaine de NIS2 ». Effectivement, rien le 17 octobre et toujours en attente d’un vote final mi-2026.

Quelques semaines auparavant, le 9 juin, Emmanuel Macron décidait de dissoudre l’Assemblée nationale. Le gouvernement démissionnaire s’occupait alors simplement d’expédier « les affaires courantes ». Les gouvernements se sont ensuite enchaînés : Attal, Barnier et Bayrou sur les derniers mois de 2024. NIS2 n’était pas la priorité des équipes respectives.

Passage au Sénat début 2025

Début 2025, les transpositions des directives européennes NIS2, DORA et REC passaient l’étape du Sénat. Avant d’être applicable, le texte doit aussi être examiné par l’Assemblée nationale. Nous avions contacté la Commission des lois à l’époque, qui nous répondait que le gouvernement avait évoqué la fin mai (spoiler : c’est loin d’être le cas), mais que la date précise ne serait connue qu’un mois avant environ.

En juin, la Cour des comptes publiait un long rapport sur la cybersécurité et y parlait évidemment de NIS2. Elle souhaitait à ce sujet que l’ANSSI évolue davantage vers une logique de contrôle et de sanction. Vincent Strubel a déjà fait part de son opposition à plusieurs reprises, affirmant son rôle de cyber-pompier et pas cyber-gendarme: « Un cyber pompier, ça ne remplit pas un PV en même temps que ça a éteint le feu ».

• Cybersécurité : les ambitions de NIS 2 décortiquées par Vincent Strubel (ANSSI)

En commission spéciale de l’Assemblée nationale en septembre 2025

En septembre 2025, le projet de loi était adopté par une commission spéciale de l’Assemblée nationale. Philippe Latombe, président de cette commission, ajoutait au passage un amendement afin de sanctuariser le chiffrement de bout en bout (dans l’article 16 bis). Ne restait donc que l’examen final du texte et son vote en séance publique.

Quelques semaines plus tard, toujours sans passage à l’Assemblée nationale (ni calendrier prévisionnel), l’ANSSI ouvrait son bureau de pré-enregistrement. C’était « la première brique de l’entrée en vigueur de NIS 2 et un premier pas pour les entités dans le respect de leurs obligations ».

Blocage début 2025 : il faut choisir entre « plusieurs mauvaises solutions »

En février, retournement de situation : la DGSI était accusée par deux députés (les présidents de la commission spéciale) de bloquer l’adoption de la loi. « Je le dis de façon claire et je ne vais pas me faire de copains en disant ça mais c’est pas grave, la DGSI et les services veulent la fin de l’article 16 bis », expliquait Philippe Latombe en conférence de presse.

En mars, l’ANSSI publiait son REférentiel CYber France (ReCyF), en version bêta. Il « liste les mesures recommandées par l’ANSSI pour atteindre les objectifs de sécurité fixés par NIS2 ». Vincent Strubel expliquait qu’il « restera un document de travail jusqu’à la transposition de NIS2 en droit français, mais il ne faut surtout pas attendre pour le mettre en œuvre ».

En avril, Vincent Strubel revenait une nouvelle fois sur ce sujet et expliquait l’impasse actuelle : « On est face à deux impératifs de même valeur : celui de la protection de la vie privée et de la sécurité nationale […]. S’il y avait une solution magique qui permette de les préserver ensemble sans impact sur l’un ou sur l’autre, elle aurait déjà été trouvée… In fine, cela relèvera d’une décision politique du législateur, qui sera un choix entre plusieurs mauvaises solutions ».

• La DGSI accusée de bloquer l’adoption d’une loi renforçant la cybersécurité

Dix-huit mois après la date butoir de transposition, la Commission supérieure du numérique et des postes (CSNP) venait mettre son grain de sel. Elle expliquait que ce retard venait « d’un point de clivage politique : l’article 16 bis, introduit au Sénat afin de consacrer dans la loi la protection du chiffrement et d’interdire l’imposition de dispositifs de portes dérobées (« backdoors ») aux messageries instantanées, fait l’objet d’une opposition du gouvernement ».

Toujours selon la Commission, le programme législatif du gouvernement « prévoit désormais un examen du texte en juillet 2026, et ce sous réserve de la convocation d’une session extraordinaire ». Caramba, encore raté.

NIS2 aux abonnés absents de la session extraordinaire de juillet

Comme le rapporte Éric Bothorel sur X, un décret a bien été publié au Journal officiel pour une convocation du Parlement en session extraordinaire à partir du mercredi 1ᵉʳ juillet 2026. Les députés devraient siéger jusqu’à la semaine du 20 juillet incluse pour examiner plusieurs textes.

L’ordre du jour comprend une trentaine d’examens sur des projets et propositions de loi. Mais, on a beau chercher, rien sur NIS2 ou le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité (le mot cyber n’apparait pas dans le décret).

Il y a quelques jours, nous apprenions que l’Europe serait sur le point de déposer plainte contre la France (devant la Cour de justice de l’Union européenne) pour son retard dans la transposition de la directive. Sur le site de l’European Cyber Security Organisation (ECSO), on peut voir que l’Espagne, l’Irlande et les Pays-Bas sont également en retard et n’ont toujours pas de transposition.

On se souviendra d’une phrase de Vincent Strubel aux Assises de la cybersécurité de Monaco en octobre 2025 à propos de l’ultime vote de la transposition de NIS2 en droit français : c’est « une étape indispensable et essentielle, mais ce n’est qu’une étape et pas la plus difficile ». Pas si sûr.

À leurs actes manqués

Alors que la transposition de NIS2 était prévue avant la fin de l’été, ce ne sera finalement pas le cas. Les députés sont certes convoqués pour une session extraordinaire, mais NIS2 n’est pas au programme de la trentaine de projets de loi qui va être examinée.

Date limite : octobre 2024

17 octobre 2024 : c’était la date limite pour transposer le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, plus connu sous le nom NIS2. Vincent Strubel (patron de l’ANSSI) avait déjà prévenu début 2024 : « le 17 octobre, il ne va pas se passer grand-chose de spécial, en tout cas dans le domaine de NIS2 ». Effectivement, rien le 17 octobre et toujours en attente d’un vote final mi-2026.

Quelques semaines auparavant, le 9 juin, Emmanuel Macron décidait de dissoudre l’Assemblée nationale. Le gouvernement démissionnaire s’occupait alors simplement d’expédier « les affaires courantes ». Les gouvernements se sont ensuite enchaînés : Attal, Barnier et Bayrou sur les derniers mois de 2024. NIS2 n’était pas la priorité des équipes respectives.

Passage au Sénat début 2025

Début 2025, les transpositions des directives européennes NIS2, DORA et REC passaient l’étape du Sénat. Avant d’être applicable, le texte doit aussi être examiné par l’Assemblée nationale. Nous avions contacté la Commission des lois à l’époque, qui nous répondait que le gouvernement avait évoqué la fin mai (spoiler : c’est loin d’être le cas), mais que la date précise ne serait connue qu’un mois avant environ.

En juin, la Cour des comptes publiait un long rapport sur la cybersécurité et y parlait évidemment de NIS2. Elle souhaitait à ce sujet que l’ANSSI évolue davantage vers une logique de contrôle et de sanction. Vincent Strubel a déjà fait part de son opposition à plusieurs reprises, affirmant son rôle de cyber-pompier et pas cyber-gendarme: « Un cyber pompier, ça ne remplit pas un PV en même temps que ça a éteint le feu ».

• Cybersécurité : les ambitions de NIS 2 décortiquées par Vincent Strubel (ANSSI)

En commission spéciale de l’Assemblée nationale en septembre 2025

En septembre 2025, le projet de loi était adopté par une commission spéciale de l’Assemblée nationale. Philippe Latombe, président de cette commission, ajoutait au passage un amendement afin de sanctuariser le chiffrement de bout en bout (dans l’article 16 bis). Ne restait donc que l’examen final du texte et son vote en séance publique.

Quelques semaines plus tard, toujours sans passage à l’Assemblée nationale (ni calendrier prévisionnel), l’ANSSI ouvrait son bureau de pré-enregistrement. C’était « la première brique de l’entrée en vigueur de NIS 2 et un premier pas pour les entités dans le respect de leurs obligations ».

Blocage début 2025 : il faut choisir entre « plusieurs mauvaises solutions »

En février, retournement de situation : la DGSI était accusée par deux députés (les présidents de la commission spéciale) de bloquer l’adoption de la loi. « Je le dis de façon claire et je ne vais pas me faire de copains en disant ça mais c’est pas grave, la DGSI et les services veulent la fin de l’article 16 bis », expliquait Philippe Latombe en conférence de presse.

En mars, l’ANSSI publiait son REférentiel CYber France (ReCyF), en version bêta. Il « liste les mesures recommandées par l’ANSSI pour atteindre les objectifs de sécurité fixés par NIS2 ». Vincent Strubel expliquait qu’il « restera un document de travail jusqu’à la transposition de NIS2 en droit français, mais il ne faut surtout pas attendre pour le mettre en œuvre ».

En avril, Vincent Strubel revenait une nouvelle fois sur ce sujet et expliquait l’impasse actuelle : « On est face à deux impératifs de même valeur : celui de la protection de la vie privée et de la sécurité nationale […]. S’il y avait une solution magique qui permette de les préserver ensemble sans impact sur l’un ou sur l’autre, elle aurait déjà été trouvée… In fine, cela relèvera d’une décision politique du législateur, qui sera un choix entre plusieurs mauvaises solutions ».

• La DGSI accusée de bloquer l’adoption d’une loi renforçant la cybersécurité

Dix-huit mois après la date butoir de transposition, la Commission supérieure du numérique et des postes (CSNP) venait mettre son grain de sel. Elle expliquait que ce retard venait « d’un point de clivage politique : l’article 16 bis, introduit au Sénat afin de consacrer dans la loi la protection du chiffrement et d’interdire l’imposition de dispositifs de portes dérobées (« backdoors ») aux messageries instantanées, fait l’objet d’une opposition du gouvernement ».

Toujours selon la Commission, le programme législatif du gouvernement « prévoit désormais un examen du texte en juillet 2026, et ce sous réserve de la convocation d’une session extraordinaire ». Caramba, encore raté.

NIS2 aux abonnés absents de la session extraordinaire de juillet

Comme le rapporte Éric Bothorel sur X, un décret a bien été publié au Journal officiel pour une convocation du Parlement en session extraordinaire à partir du mercredi 1ᵉʳ juillet 2026. Les députés devraient siéger jusqu’à la semaine du 20 juillet incluse pour examiner plusieurs textes.

L’ordre du jour comprend une trentaine d’examens sur des projets et propositions de loi. Mais, on a beau chercher, rien sur NIS2 ou le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité (le mot cyber n’apparait pas dans le décret).

Il y a quelques jours, nous apprenions que l’Europe serait sur le point de déposer plainte contre la France (devant la Cour de justice de l’Union européenne) pour son retard dans la transposition de la directive. Sur le site de l’European Cyber Security Organisation (ECSO), on peut voir que l’Espagne, l’Irlande et les Pays-Bas sont également en retard et n’ont toujours pas de transposition.

On se souviendra d’une phrase de Vincent Strubel aux Assises de la cybersécurité de Monaco en octobre 2025 à propos de l’ultime vote de la transposition de NIS2 en droit français : c’est « une étape indispensable et essentielle, mais ce n’est qu’une étape et pas la plus difficile ». Pas si sûr.

Kyiv peut désormais activer l'assistance d'urgence européenne face aux cyberattaques de grande ampleur. Une décision symbolique autant que stratégique.

Mon seignaur, il est l'AUR de se protéger

Une attaque non revendiquée a permis à des pirates d’infecter des centaines de paquets dans le dépôt AUR d’Arch Linux. La distribution n’est pas directement touchée, le dépôt étant consacré aux paquets gérés par la communauté. L’ampleur de l’attaque montre une nouvelle fois les limites d’un modèle de sécurité avant tout basé sur la confiance.

AUR, pour Arch User Repository, est un dépôt communautaire pour la distribution Arch Linux (et celles qui en dérivent). Comme indiqué sur le wiki d’Arch Linux, il « a été créé pour organiser et partager les nouveaux paquets de la communauté et pour aider à accélérer l’inclusion des paquets populaires dans le dépôt « extra » ». Il n’est donc pas géré par l’équipe de maintenance d’Arch Linux, n’est le plus souvent pas activé par défaut et contient un grand nombre de paquets (archives regroupant les fichiers nécessaires à un logiciel et les métadonnées associées) non présents dans la distribution.

Pratique, AUR est aussi un fourre-tout dans lequel la traçabilité est parfois très relative. C’est cet aspect qui a été exploité par les pirates.

L’attaque

Le 11 juin, les chercheurs de l’entreprise de sécurité Sonatype découvrent une campagne d’attaque coordonnée contre le dépôt AUR. Le ou les pirates ont pris le contrôle de paquets AUR dits « orphelins », c’est-à-dire abandonnés et en quête d’un repreneur. Ces paquets ont été modifiés : les fichiers de description des paquets (PKGBUILD) pointent vers un paquet npm malveillant à l’installation.

Dans son billet, Sonatype indique qu’une vingtaine de paquets modifiés ont ainsi été détectés. Un script post-installation a même été injecté pour appeler la commande « npm install atomic-lockfile ».

Entre les 11 et 12 juin, le nombre de paquets détectés comme malveillants s’envole, comme rapporté par le collectif de renseignement open source IFIN (Independent Federated Intelligence Network) et la communauté AUR. On passe ainsi de 20 à plus de 400 paquets, qui distribuent à la fois un rootkit assurant la persistance dans les machines infectées et un malware dédié au vol d’identifiants et de jetons d’accès (tokens d’authentification).

Le loup dans la bergerie

Aqara, fabricant d’appareils connectés populaires dans l’univers HomeKit, a récemment corrigé la bagatelle de 26 défaillances de sécurité détectées principalement au niveau de la plateforme cloud qui sous-tend ses services. Dix des failles découvertes ont donné lieu à publication d’une CVE. L’exploitation combinée des quatre premières aboutit à une vulnérabilité notée 10, le niveau maximal de sévérité.

Une recherche indépendante, publiée le 11 juin dernier, vient de mettre en lumière un vaste ensemble de vulnérabilités affectant les produits de la marque Aqara. Ce fabricant chinois commercialise pour mémoire une large gamme de capteurs de température, caméras IP, ampoules pilotées, thermostats et autres serrures ou verrous connectés. La bonne intégration de ses produits dans Apple Maison (HomeKit) les rend particulièrement populaires chez les amateurs de domotique.

La plateforme cloud qui sous-tend leur fonctionnement présentait toutefois quelques sérieuses failles en matière de sécurité. L’exploitation combinée de plusieurs d’entre elles créait ainsi une voie pour usurper n’importe quel compte enregistré sur la plateforme Aqara, et donc potentiellement de forger un accès à l’ensemble de l’écosystème domotique d’un utilisateur.

Dix CVE et de nombreux problèmes de configuration

L’une de ces failles a reçu la note maximale de 10.0 dans la base de Common Vulnerabilities and Exposures (CVE) officielle – une sévérité qui reflète son rôle dans la chaîne plutôt que son impact pris isolément, le chercheur lui ayant lui-même attribué 7.5. « La passerelle Aqara IAM/SSO (gw-builder.aqara.com) expose des échanges AES bidirectionnels contre la clé de signature de la plateforme sans authentification », indique la notice associée.

Derrière ce scénario du pire (dont aucune mise en œuvre malveillante n’a été attestée) se cache en réalité un catalogue de failles et de lacunes de sécurité bien plus vastes, comme le présente sur GitHub l’auteur de ces découvertes, le Français Sammy Azdoufal. Ses travaux, confirmés par Tod Beardsley de runZero, ont donné lieu à la publication de dix CVE individuelles, dont quatre sont qualifiées de critiques (note supérieure à 9).

« L’audit a révélé dix vulnérabilités côté produit suffisamment graves pour justifier l’attribution de CVE, ainsi que onze problèmes côté opérateur affectant l’infrastructure d’Aqara (son CRM, ses plateformes CI/opérations internes, sa passerelle IAM, son forum et son GitHub). Les quatre premières CVE sont liées entre elles. Aucune d’entre elles n’atteint individuellement le niveau 10.0. C’est leur enchaînement qui aboutit à ce niveau », décrit Sammy Azdoufal.

Il a découvert ces failles en étudiant l’application mobile dédiée à ses utilisateurs, ce qui lui avait déjà permis de découvrir plus d’un million de babyphones espion basés sur le cloud Meari, et près d’un million de pièces d’identité exposées sur Internet par le fournisseur d’un outil de CRM dédié aux coffee shops et autres cannabis clubs sociaux.

Sammy Azdoufal indique avoir listé et informé Aqara d’un total de 27 défaillances. Le fabricant aurait reconnu et corrigé 26 d’entre elles, laissant de côté l’allusion à un forum Discourse dont les messages et les comptes utilisateurs étaient accessibles sans authentification préalable. « L’un des éléments signalés comme corrigés est un problème structurel (CVE-2026-50091, clés cryptographiques codées en dur intégrées au SDK mobile et au firmware déployé) pour lequel un correctif côté serveur n’est pas architecturalement suffisant », estime de son côté l’auteur de la découverte.

La marque minimise l’impact

Il relate par ailleurs la chronologie de ses échanges avec Aqara, de la première prise de contact, en mars, à la déclaration publique transmise le 11 juin, date de la publication de ses découvertes. Dans cette dernière, telle que reproduite par Sammy Azdoufal, l’entreprise affirme que « la possibilité potentielle de contrôler les appareils des utilisateurs se rapporte à un environnement de test totalement distinct des systèmes de production d’Aqara », et que l’accès « à de véritables appareils ou comptes utilisateurs via l’environnement de test est impossible dans notre architecture, car les environnements ne partagent aucune donnée utilisateur, identifiant ni service backend ».

Des affirmations que réfute le chercheur indépendant. « Le point d’accès de récupération des jetons (famille CVE-2026-50083) a renvoyé 2 969 sessions actives, dont les sessions JWT actives de deux employés d’Aqara. Les environnements de test ne contiennent pas les sessions de travail actives des employés réels », fait-il par exemple valoir.

Nous avons contacté Aqara pour essayer de tirer au clair ces contradictions. En attendant, les utilisateurs de l’application du même nom ont sans doute tout intérêt à révoquer les autorisations tierces qu’ils n’auraient pas eux-mêmes accordées dans les paramètres de leur compte. Ainsi qu’à privilégier les options de contrôle local, notamment via HomeKit, plutôt que de piloter leurs appareils par l’intermédiaire d’un cloud opéré par le fabricant. Un conseil qui vaut sans doute d’ailleurs bien au-delà du cas particulier d’Aqara…

• Domotique « intelligente » : ne nous laissons pas enfermer par nos objets connectés

Le loup dans la bergerie

Aqara, fabricant d’appareils connectés populaires dans l’univers HomeKit, a récemment corrigé la bagatelle de 26 défaillances de sécurité détectées principalement au niveau de la plateforme cloud qui sous-tend ses services. Dix des failles découvertes ont donné lieu à publication d’une CVE. L’exploitation combinée des quatre premières aboutit à une vulnérabilité notée 10, le niveau maximal de sévérité.

Une recherche indépendante, publiée le 11 juin dernier, vient de mettre en lumière un vaste ensemble de vulnérabilités affectant les produits de la marque Aqara. Ce fabricant chinois commercialise pour mémoire une large gamme de capteurs de température, caméras IP, ampoules pilotées, thermostats et autres serrures ou verrous connectés. La bonne intégration de ses produits dans Apple Maison (HomeKit) les rend particulièrement populaires chez les amateurs de domotique.

La plateforme cloud qui sous-tend leur fonctionnement présentait toutefois quelques sérieuses failles en matière de sécurité. L’exploitation combinée de plusieurs d’entre elles créait ainsi une voie pour usurper n’importe quel compte enregistré sur la plateforme Aqara, et donc potentiellement de forger un accès à l’ensemble de l’écosystème domotique d’un utilisateur.

Dix CVE et de nombreux problèmes de configuration

L’une de ces failles a reçu la note maximale de 10.0 dans la base de Common Vulnerabilities and Exposures (CVE) officielle – une sévérité qui reflète son rôle dans la chaîne plutôt que son impact pris isolément, le chercheur lui ayant lui-même attribué 7.5. « La passerelle Aqara IAM/SSO (gw-builder.aqara.com) expose des échanges AES bidirectionnels contre la clé de signature de la plateforme sans authentification », indique la notice associée.

Derrière ce scénario du pire (dont aucune mise en œuvre malveillante n’a été attestée) se cache en réalité un catalogue de failles et de lacunes de sécurité bien plus vastes, comme le présente sur GitHub l’auteur de ces découvertes, le Français Sammy Azdoufal. Ses travaux, confirmés par Tod Beardsley de runZero, ont donné lieu à la publication de dix CVE individuelles, dont quatre sont qualifiées de critiques (note supérieure à 9).

« L’audit a révélé dix vulnérabilités côté produit suffisamment graves pour justifier l’attribution de CVE, ainsi que onze problèmes côté opérateur affectant l’infrastructure d’Aqara (son CRM, ses plateformes CI/opérations internes, sa passerelle IAM, son forum et son GitHub). Les quatre premières CVE sont liées entre elles. Aucune d’entre elles n’atteint individuellement le niveau 10.0. C’est leur enchaînement qui aboutit à ce niveau », décrit Sammy Azdoufal.

Il a découvert ces failles en étudiant l’application mobile dédiée à ses utilisateurs, ce qui lui avait déjà permis de découvrir plus d’un million de babyphones espion basés sur le cloud Meari, et près d’un million de pièces d’identité exposées sur Internet par le fournisseur d’un outil de CRM dédié aux coffee shops et autres cannabis clubs sociaux.

Sammy Azdoufal indique avoir listé et informé Aqara d’un total de 27 défaillances. Le fabricant aurait reconnu et corrigé 26 d’entre elles, laissant de côté l’allusion à un forum Discourse dont les messages et les comptes utilisateurs étaient accessibles sans authentification préalable. « L’un des éléments signalés comme corrigés est un problème structurel (CVE-2026-50091, clés cryptographiques codées en dur intégrées au SDK mobile et au firmware déployé) pour lequel un correctif côté serveur n’est pas architecturalement suffisant », estime de son côté l’auteur de la découverte.

La marque minimise l’impact

Il relate par ailleurs la chronologie de ses échanges avec Aqara, de la première prise de contact, en mars, à la déclaration publique transmise le 11 juin, date de la publication de ses découvertes. Dans cette dernière, telle que reproduite par Sammy Azdoufal, l’entreprise affirme que « la possibilité potentielle de contrôler les appareils des utilisateurs se rapporte à un environnement de test totalement distinct des systèmes de production d’Aqara », et que l’accès « à de véritables appareils ou comptes utilisateurs via l’environnement de test est impossible dans notre architecture, car les environnements ne partagent aucune donnée utilisateur, identifiant ni service backend ».

Des affirmations que réfute le chercheur indépendant. « Le point d’accès de récupération des jetons (famille CVE-2026-50083) a renvoyé 2 969 sessions actives, dont les sessions JWT actives de deux employés d’Aqara. Les environnements de test ne contiennent pas les sessions de travail actives des employés réels », fait-il par exemple valoir.

Nous avons contacté Aqara pour essayer de tirer au clair ces contradictions. En attendant, les utilisateurs de l’application du même nom ont sans doute tout intérêt à révoquer les autorisations tierces qu’ils n’auraient pas eux-mêmes accordées dans les paramètres de leur compte. Ainsi qu’à privilégier les options de contrôle local, notamment via HomeKit, plutôt que de piloter leurs appareils par l’intermédiaire d’un cloud opéré par le fabricant. Un conseil qui vaut sans doute d’ailleurs bien au-delà du cas particulier d’Aqara…

• Domotique « intelligente » : ne nous laissons pas enfermer par nos objets connectés

Le mot du jour est : doxing !

Trouver des informations personnelles, bancaires d’une personne aussi facilement que la recette de la tarte aux pommes ? C’est la « promesse » d’un site qui commercialise désormais vos données privées et bancaires, dont l’histoire mérite qu’on s’y attarde. Le gouvernement a saisi la justice.

Mise à jour du 13 juin 11h38. Le député Éric Bothorel annonce avoir « saisi hier la Justice pour au moins trois sites qui compilent des fuites de données et les rendent publiques » et rappelle au passage les risques.

Article original du 12 juin 22h00. Depuis plusieurs mois, un moteur de recherche fait tout pour se faire connaître. Se présentant comme un service agrégeant les données publiques et issues des (nombreuses) fuites qui surviennent en France depuis des années, il permet de chercher très simplement les informations d’une personne. Les critiques sur sa licéité et les retombées sur la vie privée n’ont pas manqué.

Avant toute chose, un point important : Next ne donnera ni son URL ni son nom, même s’ils sont facilement trouvables (et nous vous demandons de faire de même dans les commentaires), notamment pour ne pas leur faire la moindre publicité gratuite.

Une fenêtre sur les fuites de données et leurs dangers

Le site apparait sous une forme simple : on s’inscrit avec son email puis on lance une recherche sur un nom et un prénom, par exemple. Les résultats apparaissent sous forme de liste, les données d’une personne étant réunies dans un cadre. On y retrouve les nom, prénom, adresses email, numéros de téléphone mobile et fixe, l’adresse postale et, selon les cas, des informations beaucoup plus sensibles comme le numéro de sécurité sociale et jusqu’à l’IBAN.

Il s’agit de données provenant des fuites de données massives, comme celles des deux prestataires du tiers payant (Viamedis et Almerys), des comptes avec IBAN de Bouygues Telecom et Free, des associations sportives, etc. Certaines sont datées, d’autres plus récentes, mais on peut assez facilement retrouver des personnes en choisissant les bons mots clés. Toujours sur Discord, les « leaks » récupérés sont listés, le premier remonte à octobre 2015 avec des données des impôts français, puis MYM, Carte Jeune Occitanie, CAF, France Travail, etc.

• Fuite d’IBAN : quels sont les risques, comment se protéger
• Prestataires du tiers payant piratés : la moitié des Français concernés, la CNIL ouvre une enquête

Malheureusement, rien de neuf, aurions-nous presque envie de dire. Les fuites sont monnaie courante depuis des années, les données facilement accessibles sur Internet. Pour Next et des experts en cybersécurité, ce n’est pas une surprise. Ce genre de « service » existe depuis des années, mais ils sont par contre plus underground, au sein de forums spécialisés plus ou moins référencés, dans des groupes de discussions, également sur des sites, mais plus confidentiels.

La « nouveauté » est ici l’accès gratuit, avec une interface propre et simple à utiliser par n’importe qui, avec une certaine viralité (même si elle est difficile à mesurer). C’est une fenêtre ouverte sur un monde qui n’est généralement pas autant sous le feu des projecteurs.

Ce site n’est d’ailleurs pas nouveau, à en croire son Discord au début de l’année : « Notre nom de domaine a récemment été supprimé, ce qui nous a obligés à le changer ». Sur le Discord, on peut également voir des guerres de clocher (ou de cour de récré quand on voit le niveau de certains échanges) sur qui a le meilleur service, qui copie l’autre, qui était là en premier, etc.

Première dose gratuite, maintenant payez (ou faites la promotion)

La période de « gratuité » est désormais terminée : l’accès est payant depuis ce vendredi. Comptez 10 euros par semaine minimum, sachant que « les prix vont augmenter prochainement », prévient le site. Pour payer, « cryptomonnaies, Paypal, PaySafeCard ou en virement bancaire ». Bien évidemment, on ne peut que vous conseiller de ne pas payer.

Cette bascule devait intervenir le 15 juin, mais elle a été faite plus tôt que prévu : « Le projet a pris une trop grande ampleur et certaines personnes jalouses qui se sont intéressées à des choses qui ne les concernaient pas ont tout fait pour essayer de faire fermer le site et nous apporter des soucis », peut-on lire dans les « annonces ».

Le besoin de viralité est d’ailleurs assumé et même monétisé, comme en témoigne le Discord pas plus tard que cette semaine : « Nous recherchons actuellement des personnes motivées pour nous aider à faire connaître xxx sur les réseaux sociaux et les communautés en ligne. Si vous êtes actif sur TikTok, Snapchat, Instagram, Discord ou toute autre plateforme et que vous souhaitez participer à la promotion du projet, n’hésitez pas à nous contacter. En échange d’une aide régulière et sérieuse, nous pourrons offrir un abonnement à l’un de nos plans payants ».

Retrouver ses proches ? La fausse bonne excuse

Nous avons contacté les gestionnaires du site via le Discord. Plusieurs ont répondu présent, de manière polie. Nous avons pu discuter oralement avec l’un d’eux, qui se fait appeler Zalko, et lui avons posé quelques questions.

Interrogé sur les motivations qui ont mené à la création du site, il nous répond qu’avec plusieurs amis, ils voulaient constituer une base rassemblant « tout ce que l’on peut trouver publiquement et dans les fuites de données ». Il ajoute : « On voulait juste que tout soit au même endroit pour simplifier la vie des gens qui veulent retrouver un proche, un ami ».

Devant les inévitables sujets relatifs à la vie privée, aux dérives comme le doxxing ou encore au caractère légal du service, Zalko est confiant : « Je ne pense pas que ce soit illégal, parce qu’on peut trouver ces données n’importe où. Nous on a simplement rassemblé tout au même endroit. On s’est beaucoup renseigné sur les textes de lois ».

Et sur l’exploitation malveillante d’une telle masse de données ? « Nous on est clairs, on avertit partout que le doxxing et ces autres pratiques sont interdites. Et on a mis en place des protections pour limiter et bloquer le scrapping ».

Nous n’en avons pas appris beaucoup plus, mais la suite a pris rapidement une tournure étrange. Une autre personne, se présentant comme un responsable du site, nous a recommandé de ne pas croire le dénommé Zalko, pourtant rangé dans les « Managers » sur Discord.

Les questions suivantes, notamment sur la licéité du service et son exploitation commerciale, n’ont reçu aucune réponse. « J’ai reçu pour instruction de ne plus vous parler », nous a répondu l’autre personne. Quand on parle de cour de récréation…

 « Sur la forme, c’est manifestement illicite »

Dans un long message signé « l’équipe xxx », les responsables affirment que ce service « est, et a toujours été, un service légal et conforme. Notre outil agrège exclusivement des données publiquement accessibles. Nous ne piratons rien. Nous ne volons rien. Nous ne doxxons personne. Nous ne leakons aucun mail confidentiel. Nous n’intimidons aucun plaignant. Nous ne redirigeons personne vers des sites malveillants. Nous n’avons aucune faille de sécurité exposant les données de nos utilisateurs. Xxx respecte le cadre légal en vigueur, y compris le RGPD. Les données accessibles via notre plateforme sont des données déjà publiques ». Sur un malentendu ?

Concernant le caractère légal d’un tel site, Alexandre Archambault, avocat spécialisé dans le droit du numérique, n’est pas catégorique mais souligne d’importants manques et zones d’ombre. « Sur la forme, c’est manifestement illicite en l’absence de mentions légales conformes à la loi, s’agissant d’un site qui s’adresse au marché français », nous indique l’avocat.

« L’exploitation d’un site internet ne disposant pas de mentions légales conformes à la loi est un délit », ajoute-t-il. Les peines peuvent aller jusqu’à 75 000 euros d’amende et un an d’emprisonnement. S’il s’agit d’une entreprise, l’amende peut s’envoler à 375 000 euros.

Il souligne qu’une telle situation peut relever des dispositions de l’article 323-3-2 du code pénal, avec un risque accru depuis la loi 2025 - 532 du 13 juin 2025. S’agissant d’une structure a priori commerciale, la bande organisée peut être retenue. Les peines encourues changent effectivement d’échelle, puisqu’elles peuvent grimper jusqu’à 10 ans d’emprisonnement et 1 million d’euros d’amende.

Des risques réels : le « recel de data volées est un crime »

Projet Arcadie est plus directe : « Techniquement, c’est du recel et cela a été confirmé par la Cour de cassation dans un arrêt du 18 février 2026 ». Tris Acatrinei se fait l’écho d’Amélie Bonfanti (cabinet Deshoulières Avocats) : « Le fait de bénéficier, en connaissance de cause, d’une information provenant d’un délit peut constituer un recel au sens de l’article 321 - 1, alinéa 2, du Code pénal ».

« L’autre véritable danger réside dans la possibilité qu’une personne très mal intentionnée qui utiliserait ces données, obtenues illégalement, pour faire du mal à quelqu’un d’autre. Dans ce cas, la responsabilité des créateurs de xxx pourrait être engagée », ajoute Projet Arcadie.

Anne Le Hénanff, ministre déléguée chargée du Numérique, affirme à BFMTV avoir saisi la justice en vertu de l’article 40 du code de procédure pénale : « Toute autorité constituée, tout officier public ou fonctionnaire qui, dans l’exercice de ses fonctions, acquiert la connaissance d’un crime ou d’un délit est tenu d’en donner avis sans délai au procureur de la République et de transmettre à ce magistrat tous les renseignements, procès-verbaux et actes qui y sont relatifs ».

Éric Bothorel a aussi saisi la justice, pour au moins trois sites similaires. Le député rappelle au passage que « sur d’autres affaires similaires, plusieurs personnes ont déjà été déférées. Il faut le redire avec force : le recel de data volées est un crime. Et à ceux qui s’y emploient, parfois très jeunes, ceci n’est pas un jeu »

Passez votre chemin, vraiment !

Rappelons enfin qu’il n’est pas du tout recommandé d’utiliser ce genre de service, notamment car vous ne savez pas ce qu’il adviendra de vos données personnelles. Pendant la phase « gratuite », ce site demandait un simple email pour se connecter (avec confirmation), vous pouviez également demander à retirer des informations.

Non seulement rien ne certifie que cela sera fait, mais même dans le meilleur des cas cela ne les supprime que de ce service… or il en existe des dizaines au bas mot, sans compter les copies des leaks qui sont un peu partout sur Internet. De plus, demander à retirer les données peut confirmer à des pirates que ces données sont encore valables, et qu’elles ont donc une valeur supplémentaire.

Vous voulez savoir si des données personnelles ont fuité ? Il existe des sites fiables, qui ne donnent pas d’informations à n’importe qui. Have I Been Pwned en est un. Entrez votre email et vérifiez dans quels leaks il apparait, avec quelles données associées.

Par exemple, l’un de nos emails est dans cette base qui est disponible sur Internet :