Un nouveau malware détecté par les chercheurs de XLab exploite des failles vieilles de plus de dix ans pour constituer discrètement une infrastructure d'attaque mondiale. Ses victimes ne savent généralement pas qu'elles en font partie.
Les agences de cybersécurité des Five Eyes n’ont pas l’habitude de communiquer publiquement, mais elles ont fait une exception. Nous ne serions qu’à quelques mois d’un modèle IA de frontière capable de démultiplier les capacités des attaquants comme des défenseurs.
L’alliance Five Eyes, composée des agences de renseignement des États-Unis, du Canada, du Royaume-Uni, de l’Australie et de la Nouvelle-Zélande, préfère travailler dans la discrétion. Mais exceptionnellement, elle a publié un communiqué sur les dangers que font peser les modèles IA de frontière.
« Les modèles d’IA les plus avancés devraient dépasser les attentes actuelles du secteur et transformer en profondeur les capacités offensives comme défensives dans le cyberespace », écrivent-elles dans une déclaration reprise par The Guardian. « L’horizon n’est pas de plusieurs années, mais de quelques mois. » Et ces modèles posent des risques qui « ne peuvent plus être considérés comme une question purement technique », préviennent-elles.
Ces modèles constituent désormais « un risque stratégique pour les entreprises et une responsabilité directe des dirigeants. Une mobilisation de l’ensemble des organisations et de la société est nécessaire ». En résumé, selon les Five Eyes, les avancées de l’IA vont faciliter l’accès à des capacités offensives pour les acteurs malveillants, tout en rendant les cyberattaques plus rapides et plus sophistiquées.
L’avertissement ne tombe pas au hasard : mi-juin, le gouvernement américain interdisait à Anthropic de donner accès à ses modèles les plus performants – Fable 5 et Mythos 5 – à « tout ressortissant étranger, qu’il soit à l’intérieur ou à l’extérieur des États-Unis ». L’entreprise a préféré couper le robinet à l’ensemble de ses clients.
Le communiqué n’est pas sans rappeler le discours d’Anthropic qui, depuis la présentation de Mythos, multiplie les déclarations catastrophistes sur les possibilités de ces modèles très performants. Une manière pour le labo IA de faire sa promo, mais au vu des premiers résultats obtenus via le projet Glasswing (chez Firefox, par exemple), les capacités de détection des failles de sécurité de Mythos ne sont pas à prendre à la légère.
Reste à voir maintenant de quelle manière cet appel des Five Eyes va être entendu par le reste du monde. Les États-Unis semblent jusqu’à présent vouloir faire à leur façon, sans prendre en compte les intérêts de leurs alliés. Cette déclaration commune pourrait tout de même indiquer une certaine inflexion de l’isolationnisme états-unien en la matière.
Les agences de cybersécurité des Five Eyes n’ont pas l’habitude de communiquer publiquement, mais elles ont fait une exception. Nous ne serions qu’à quelques mois d’un modèle IA de frontière capable de démultiplier les capacités des attaquants comme des défenseurs.
L’alliance Five Eyes, composée des agences de renseignement des États-Unis, du Canada, du Royaume-Uni, de l’Australie et de la Nouvelle-Zélande, préfère travailler dans la discrétion. Mais exceptionnellement, elle a publié un communiqué sur les dangers que font peser les modèles IA de frontière.
« Les modèles d’IA les plus avancés devraient dépasser les attentes actuelles du secteur et transformer en profondeur les capacités offensives comme défensives dans le cyberespace », écrivent-elles dans une déclaration reprise par The Guardian. « L’horizon n’est pas de plusieurs années, mais de quelques mois. » Et ces modèles posent des risques qui « ne peuvent plus être considérés comme une question purement technique », préviennent-elles.
Ces modèles constituent désormais « un risque stratégique pour les entreprises et une responsabilité directe des dirigeants. Une mobilisation de l’ensemble des organisations et de la société est nécessaire ». En résumé, selon les Five Eyes, les avancées de l’IA vont faciliter l’accès à des capacités offensives pour les acteurs malveillants, tout en rendant les cyberattaques plus rapides et plus sophistiquées.
L’avertissement ne tombe pas au hasard : mi-juin, le gouvernement américain interdisait à Anthropic de donner accès à ses modèles les plus performants – Fable 5 et Mythos 5 – à « tout ressortissant étranger, qu’il soit à l’intérieur ou à l’extérieur des États-Unis ». L’entreprise a préféré couper le robinet à l’ensemble de ses clients.
Le communiqué n’est pas sans rappeler le discours d’Anthropic qui, depuis la présentation de Mythos, multiplie les déclarations catastrophistes sur les possibilités de ces modèles très performants. Une manière pour le labo IA de faire sa promo, mais au vu des premiers résultats obtenus via le projet Glasswing (chez Firefox, par exemple), les capacités de détection des failles de sécurité de Mythos ne sont pas à prendre à la légère.
Reste à voir maintenant de quelle manière cet appel des Five Eyes va être entendu par le reste du monde. Les États-Unis semblent jusqu’à présent vouloir faire à leur façon, sans prendre en compte les intérêts de leurs alliés. Cette déclaration commune pourrait tout de même indiquer une certaine inflexion de l’isolationnisme états-unien en la matière.
Une attaque contre la plateforme d'intelligence compétitive Klue a permis à un groupe criminel d'exfiltrer des données CRM chez des dizaines d'entreprises, dont plusieurs noms majeurs du secteur de la cybersécurité.
Il y a une semaine, une importante campagne d’attaque a été détectée contre les pare-feux Fortinet. 80 000 mots de passe ont été récupérés par des pirates, ce qui représenterait la moitié environ des pare-feux Fortinet exposés à Internet.
L’attaque a été découverte par le chercheur Volodymyr Diachenko (souvent appelé Bob). Dans une publication LinkedIn le 15 juin, il avertit qu’une « campagne massive de force brute/exploitation » a été découverte en pleine action sur des pare-feux Fortinet. Il évoque alors 21 634 noms de domaine uniques, liés à des entreprises allant de Chevron à Fortinet elle-même. Les mots de passe ont été obtenus par craquage du hachage, puis utilisés pour obtenir des données et la prise de contrôle de réseaux internes.
Selon les chercheurs de SOCRadar, le mode opératoire et les traces laissées sont à rapprocher des acteurs malveillants russes. L’attaque est décrite comme particulièrement sophistiquée, ayant abouti à un lot de données comprenant à la fois des mots de passe et des identifiants SSL VPN depuis des fichiers de configuration compromis.
Toujours selon SOCRadar, les équipements attaqués étaient répartis dans 194 pays. Les plus touchés sont l’Inde, les États-Unis et le Mexique, avec près de 12 000 identifiants compromis entre eux. La France est présente dans la liste avec 1 116 identifiants.
La répartition par type de « credentials » révèle une prédominance de comptes organisationnels, pointant vers un ciblage délibéré des entreprises. Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture et Oracle, ainsi que de nombreuses entités gouvernementales et opérateurs d’infrastructures critiques ont été touchés. Un contractant turc de l’OTAN figure également parmi les cibles.
Si l’attaque a été nommée FortiBleed, le cas n’a rien à voir avec Heartbleed : il s’agit bien d’une campagne industrielle de vol et d’utilisation d’identifiants. À la racine de l’attaque, il n’y a pas une faille unique et cataclysmique, mais une série de défaillances en lien avec l’hygiène numérique.
Selon le chercheur Kevin Beaumont dans un billet du 18 juin, les pirates ont commencé par scanner internet à la recherche d’instances Fortinet dont l’interface de gestion FortiGate était accessible publiquement. Ils se sont ensuite intéressés à celles présentant un profil spécifique.
Dans les versions 7.2.11, 7.4.8 et 7.6.1 de FortiOS, le système d’exploitation équipant ses pare-feux, Fortinet a en effet introduit la fonction de hachage PBKDF2 pour les identifiants administrateurs, pour remplacer l’ancien SHA-256. Cependant, lors d’une mise à jour depuis des versions antérieures, les mots de passe existants restent stockés en SHA-256 jusqu’à ce que l’administrateur se reconnecte après l’opération. De nombreuses organisations ont donc appliqué une nouvelle version sans déclencher de nouveau hachage : leurs firewalls, pourtant mis à jour, demeuraient vulnérables.
Les pirates ne se sont pas lancés non plus à l’aveuglette. Ils ont opéré sur la base d’identifiants déjà obtenus par plusieurs sources : la fuite Fortinet de 2021 portant sur environ 500 000 comptes FortiGate VPN, les données obtenues après une faille 0-day en 2022, ou encore d’autres bases existantes. Les mots de passe testés n’étant donc pas aléatoires : ils avaient déjà fonctionné par le passé sur des appareils Fortinet.
L’ampleur de l’attaque est connue, car les chercheurs ont pu remonter jusqu’aux pirates russes, car leur serveur était lui-même exposé publiquement. Les journaux récupérés indiquaient environ 1,16 milliard de tentatives d’identification contre 320 777 cibles FortiGate, ainsi que 2,1 milliards de tentatives supplémentaires contre plus de 163 650 serveurs Microsoft SQL Server, indique le site InfoStealers. Le groupe interceptait les hachages d’authentification SSL VPN et les crackait sur un cluster dédié de 45 GPU géré via Hashtopolis, selon Kevin Beaumont.
Au moins une faille existante pourrait avoir été utilisée : la vulnérabilité CVE-2026-24858, qui permet un contournement d’authentification SAML SSO FortiCloud et est classée comme critique, avec un score CVSS de 9,8 sur 10, comme l’indique RansomNews. Elle a été révélée en janvier et est déjà corrigée, mais des appareils ont pu passer à côté du correctif. Du côté de SOCRadar, on note que deux autres failles ont été activement exploitées pendant cette période, CVE-2026-21643 et CVE-2026-35616. Elles concernent FortiClient EMS, mais le lien avec FortiBleed n’est pas confirmé. Aucune faille 0-day ne semble avoir été utilisée.
Les recommandations sont claires :
Pour Fortinet, il ne s’agit que d’une exploitation d’anciennes bases de données. « D’après notre analyse, les données impliquées sont un mélange de données d’incidents précédents, ainsi qu’un [cracking par] force brute des identifiants, et ne sont pas liées à un incident récent ni à un avertissement. Les organisations qui suivent les meilleures pratiques, y compris la mise à jour régulière des identifiants de sécurité […] courent un risque minimal lié aux détails de compromission des identifiants mentionnés dans les rapports », a déclaré l’entreprise à TechRadar le 18 juin. Elle ajoutait cependant que l’enquête continuait et que la sécurité de ses clients restait sa priorité.
Kevin Beaumont relativise ces déclarations, précisant que les fuites contiennent des données plus récentes.
Il y a une semaine, une importante campagne d’attaque a été détectée contre les pare-feux Fortinet. 80 000 mots de passe ont été récupérés par des pirates, ce qui représenterait la moitié environ des pare-feux Fortinet exposés à Internet.
L’attaque a été découverte par le chercheur Volodymyr Diachenko (souvent appelé Bob). Dans une publication LinkedIn le 15 juin, il avertit qu’une « campagne massive de force brute/exploitation » a été découverte en pleine action sur des pare-feux Fortinet. Il évoque alors 21 634 noms de domaine uniques, liés à des entreprises allant de Chevron à Fortinet elle-même. Les mots de passe ont été obtenus par craquage du hachage, puis utilisés pour obtenir des données et la prise de contrôle de réseaux internes.
Selon les chercheurs de SOCRadar, le mode opératoire et les traces laissées sont à rapprocher des acteurs malveillants russes. L’attaque est décrite comme particulièrement sophistiquée, ayant abouti à un lot de données comprenant à la fois des mots de passe et des identifiants SSL VPN depuis des fichiers de configuration compromis.
Toujours selon SOCRadar, les équipements attaqués étaient répartis dans 194 pays. Les plus touchés sont l’Inde, les États-Unis et le Mexique, avec près de 12 000 identifiants compromis entre eux. La France est présente dans la liste avec 1 116 identifiants.
La répartition par type de « credentials » révèle une prédominance de comptes organisationnels, pointant vers un ciblage délibéré des entreprises. Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture et Oracle, ainsi que de nombreuses entités gouvernementales et opérateurs d’infrastructures critiques ont été touchés. Un contractant turc de l’OTAN figure également parmi les cibles.
Si l’attaque a été nommée FortiBleed, le cas n’a rien à voir avec Heartbleed : il s’agit bien d’une campagne industrielle de vol et d’utilisation d’identifiants. À la racine de l’attaque, il n’y a pas une faille unique et cataclysmique, mais une série de défaillances en lien avec l’hygiène numérique.
Selon le chercheur Kevin Beaumont dans un billet du 18 juin, les pirates ont commencé par scanner internet à la recherche d’instances Fortinet dont l’interface de gestion FortiGate était accessible publiquement. Ils se sont ensuite intéressés à celles présentant un profil spécifique.
Dans les versions 7.2.11, 7.4.8 et 7.6.1 de FortiOS, le système d’exploitation équipant ses pare-feux, Fortinet a en effet introduit la fonction de hachage PBKDF2 pour les identifiants administrateurs, pour remplacer l’ancien SHA-256. Cependant, lors d’une mise à jour depuis des versions antérieures, les mots de passe existants restent stockés en SHA-256 jusqu’à ce que l’administrateur se reconnecte après l’opération. De nombreuses organisations ont donc appliqué une nouvelle version sans déclencher de nouveau hachage : leurs firewalls, pourtant mis à jour, demeuraient vulnérables.
Les pirates ne se sont pas lancés non plus à l’aveuglette. Ils ont opéré sur la base d’identifiants déjà obtenus par plusieurs sources : la fuite Fortinet de 2021 portant sur environ 500 000 comptes FortiGate VPN, les données obtenues après une faille 0-day en 2022, ou encore d’autres bases existantes. Les mots de passe testés n’étant donc pas aléatoires : ils avaient déjà fonctionné par le passé sur des appareils Fortinet.
L’ampleur de l’attaque est connue, car les chercheurs ont pu remonter jusqu’aux pirates russes, car leur serveur était lui-même exposé publiquement. Les journaux récupérés indiquaient environ 1,16 milliard de tentatives d’identification contre 320 777 cibles FortiGate, ainsi que 2,1 milliards de tentatives supplémentaires contre plus de 163 650 serveurs Microsoft SQL Server, indique le site InfoStealers. Le groupe interceptait les hachages d’authentification SSL VPN et les crackait sur un cluster dédié de 45 GPU géré via Hashtopolis, selon Kevin Beaumont.
Au moins une faille existante pourrait avoir été utilisée : la vulnérabilité CVE-2026-24858, qui permet un contournement d’authentification SAML SSO FortiCloud et est classée comme critique, avec un score CVSS de 9,8 sur 10, comme l’indique RansomNews. Elle a été révélée en janvier et est déjà corrigée, mais des appareils ont pu passer à côté du correctif. Du côté de SOCRadar, on note que deux autres failles ont été activement exploitées pendant cette période, CVE-2026-21643 et CVE-2026-35616. Elles concernent FortiClient EMS, mais le lien avec FortiBleed n’est pas confirmé. Aucune faille 0-day ne semble avoir été utilisée.
Les recommandations sont claires :
Pour Fortinet, il ne s’agit que d’une exploitation d’anciennes bases de données. « D’après notre analyse, les données impliquées sont un mélange de données d’incidents précédents, ainsi qu’un [cracking par] force brute des identifiants, et ne sont pas liées à un incident récent ni à un avertissement. Les organisations qui suivent les meilleures pratiques, y compris la mise à jour régulière des identifiants de sécurité […] courent un risque minimal lié aux détails de compromission des identifiants mentionnés dans les rapports », a déclaré l’entreprise à TechRadar le 18 juin. Elle ajoutait cependant que l’enquête continuait et que la sécurité de ses clients restait sa priorité.
Kevin Beaumont relativise ces déclarations, précisant que les fuites contiennent des données plus récentes.
Initialement terminé le 14 juin dernier, l’appel à conférences du salon Open Source Experience (aka OSXP pour les intimes) est prolongé : les propositions peuvent être soumises jusqu’au 24 juin 2026 à 23 h 59. Quelques jours de plus pour finir le teaser d’un retour d’expérience, affûter un sujet technique ou sortir votre idée de conférence qui traîne dans votre pile À traiter.
Et au passage le village des associations revient en force !
Plus de détails dans la suite de la dépêche.
Suite aux demandes de plusieurs acteurs de l’écosystème que nous ne nommerons pas, car ils ont procrastinés, les organisateurs d’OSXP repoussent la date limite de soumission. L’appel vise des conférences autour du libre et l’open source (forcément) et de la souveraineté numérique (mot très à la mode), avec une préférence assumée pour le concret :
Les propositions de conférences sont donc à déposer avant le 24 juin 2026 à 23 h 59 sur la page de l'appel à conférences. Si vous avez un sujet à partager, c’est le moment de le soumettre… ou de pousser gentiment quelqu’un de votre communauté à le faire.
On profite aussi de cette dépêche pour glisser un petit teasing : l’appel à candidatures pour le village des Associations d’Open Source Experience sera bientôt relancé sur LinuxFr.org.
Et il devrait y avoir de bonnes nouvelles pour les associations du libre. On n’en dit pas plus pour l’instant — oui, c’est vilain, mais c’est pour la bonne cause — et oui, j'utilise des tirets cadratins récursifs pour ne pas les laisser aux IA ;-)
Et rendez-vous les 9 et 10 décembre 2026 à Paris, porte de Versailles.
Commentaires : voir le flux Atom ouvrir dans le navigateur
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é.
DarkMoon est un projet libre de cybersécurité publié sous licence GNU GPLv3. Il propose un moteur de test d’intrusion automatisé, lancé en conteneur Docker, qui orchestre des outils de sécurité existants, des agents spécialisés et un modèle de langage configurable.
Concrètement, l’utilisateur donne une cible autorisée. DarkMoon lance des étapes de reconnaissance, identifie des technologies exposées, choisit certains outils ou agents selon le contexte, puis produit des journaux et un rapport de pentest en Markdown.
Le projet est récent. Le premier commit visible sur GitHub date de novembre 2025, le dépôt a été rendu public en mai 2026, et une première release a été publiée récemment. Au moment de la rédaction, les mainteneurs indiquent un peu plus de 500 clonages du dépôt et environ 1300 téléchargements des images Docker. Ces éléments donnent un premier signal d’usage, sans en faire pour autant un outil éprouvé en production.
DarkMoon essaie de répondre à une question simple : peut-on automatiser une partie d’un pentest sans se limiter à lancer un scanner unique ?
Le fonctionnement attendu est le suivant :
DarkMoon est publié sous licence libre GNU GPLv3. Le dépôt GitHub contient les scripts d’installation, l’orchestration Docker, les composants de l’outil, les configurations et la documentation associée.
Le projet n’a pas vocation à remplacer l’expertise humaine d’un pentester. Il vise plutôt à automatiser des tâches répétitives, à aider à la corrélation des résultats, et à produire des sorties plus facilement exploitables. Dans un audit réel, l’interprétation, la validation des constats, la priorisation et le respect du cadre légal restent des responsabilités humaines.
L’usage prévu est strictement limité aux environnements autorisés: laboratoires, machines volontairement vulnérables, programmes de bug bounty, audits internes ou périmètres contractuels.
DarkMoon repose sur trois blocs principaux :
Connexiondarkmoon.sh pour démarrer les campagnes et suivre les journaux.La séparation entre le modèle, le contrôle et l’exécution est importante. Le modèle peut proposer une stratégie, mais les actions passent par une couche de contrôle avant d’être exécutées dans le conteneur. Cela permet de garder une trace des actions et de limiter l’exécution directe sur l’hôte.
L’installation documentée repose sur Docker et Docker Compose. L’utilisateur clone le dépôt, rend les scripts exécutables, puis lance l’installation.
git clone https://github.com/ASCIT31/Dark-Moon.git
cd Dark-Moon
chmod +x install.sh darkmoon.sh
./install.shLe script prépare l’environnement, construit les images nécessaires et initialise les volumes. Une fois l’installation terminée, DarkMoon peut être lancé depuis la racine du dépôt.
./darkmoon.shIl est aussi possible de lancer directement une cible depuis la ligne de commande.
./darkmoon.sh "TARGET: http://172.19.0.3:3000"
DarkMoon ne force pas un fournisseur unique de LLM. Lors de l’installation, on peut configurer un fournisseur cloud comme OpenAI, Anthropic ou OpenRouter, mais aussi un modèle local via Ollama, llama.cpp ou une URL compatible avec l’API OpenAI.
C’est un point important pour un outil de sécurité. Selon le contexte, on peut préférer un modèle distant plus performant, ou un modèle local pour éviter d’envoyer des informations de cible, de journaux ou de résultats vers un service externe.
Une campagne DarkMoon commence par la définition d’un périmètre. La forme minimale consiste à fournir une cible :
./darkmoon.sh "TARGET: http://172.19.0.3:3000"Une forme plus complète permet de préciser le programme, les cibles incluses, les exclusions, les familles de vulnérabilités à privilégier, le niveau de bruit acceptable et les règles d’engagement.
./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'"Après le lancement, l’outil fournit un identifiant de session. Les journaux peuvent ensuite être suivis avec:
./darkmoon.sh --log <session_id>
Une démonstration vidéo montre DarkMoon exécuté contre OWASP Juice Shop, une application volontairement vulnérable conçue pour l’apprentissage et les tests de sécurité applicative. Ce choix est important: il permet d’illustrer le fonctionnement du moteur sur une cible réaliste, mais explicitement prévue pour l’entraînement, sans viser un système tiers.
La vidéo présente le déroulement général d’une campagne: lancement depuis la ligne de commande, analyse de la cible, collecte de signaux techniques, sélection des actions à mener et production progressive d’observations exploitables. Elle permet aussi de mieux comprendre la logique d’orchestration: DarkMoon ne se limite pas à lancer un unique scanner, mais enchaîne plusieurs étapes selon ce qu’il découvre.
Lien de la démonstration : DarkMoon sur OWASP Juice Shop
L’intérêt de Juice Shop dans ce contexte est double. D’un côté, l’application contient de nombreuses familles de vulnérabilités web connues, ce qui permet de tester la capacité de détection et d’enchaînement du moteur. De l’autre, elle fournit un cadre légal et reproductible pour expérimenter l’outil, comparer les résultats et améliorer les agents sans exposer de service réel.
Le moteur commence par collecter des signaux techniques : ports ouverts, services exposés, technologies web, frameworks, CMS, API, en-têtes HTTP, chemins visibles ou comportements applicatifs.
Ces informations servent ensuite à choisir les actions suivantes. Une cible WordPress, une API GraphQL ou un environnement Kubernetes ne déclenchent pas les mêmes outils ni les mêmes agents.
DarkMoon ne réécrit pas les outils de sécurité existants. Il les regroupe dans une image Docker et les appelle selon le contexte détecté.
Parmi les outils cités dans la documentation ou dans les articles qui présentent le projet, on trouve notamment Naabu, Masscan, Nuclei, ffuf, sqlmap, Arjun, wafw00f, Subfinder, Katana, Waybackurls, httpx, WPScan, CMSeeK, Hydra, dig, ainsi que des outils liés à BloodHound, Impacket, kubectl, Kubescape ou Kubeletctl.
Le point important n’est pas la liste exacte des outils, qui peut évoluer, mais la logique d’orchestration: détecter ce qui est pertinent, lancer l’outil adapté, lire la sortie, puis décider de l’étape suivante.
Une campagne produit des journaux et des artefacts. L’utilisateur peut suivre l’exécution, consulter les étapes et récupérer les résultats dans les répertoires de sortie prévus.
DarkMoon génère aussi un rapport de pentest en Markdown. Ce choix est simple: le fichier est lisible dans un terminal, versionnable avec Git, relisible dans une forge, modifiable à la main et convertible ensuite en HTML ou en PDF.
Le rapport doit conserver le contexte de la campagne : cible, périmètre, hypothèses, commandes ou actions utiles, preuves collectées, vulnérabilités relevées, criticité, impact potentiel et pistes de correction.
DarkMoon est un outil offensif. Il doit être utilisé uniquement sur des systèmes pour lesquels l’utilisateur dispose d’une autorisation explicite: laboratoire local, machine volontairement vulnérable, programme de bug bounty, audit interne ou périmètre contractuel.
L’automatisation ne réduit pas les responsabilités de l’utilisateur: définir le périmètre, obtenir les autorisations, éviter les impacts de production et manipuler les données avec précaution.
Les limites sont celles de tout outil de pentest automatisé:
Un modèle peut proposer une action inutile, trop large ou mal adaptée au contexte. La couche de contrôle et les journaux sont donc utiles, mais ils ne dispensent pas d’une revue humaine.
Le projet est ouvert aux retours techniques. Les contributions les plus utiles concernent:
Les remarques sur la clarté du fonctionnement sont également bienvenues, surtout pour éviter de présenter l’outil comme plus mature qu’il ne l’est réellement.
Commentaires : voir le flux Atom ouvrir dans le navigateur
© PHOTO SANTIAGO ARCOS/REUTERS
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.
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.
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.
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 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.
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.
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.
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.
© PHOTO YURI CORTEZ/AFP
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.
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 :
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.
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.
© PHOTO PABLO SANHUEZA/REUTERS
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.
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.
« 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.
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 ».
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 ».
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 ».
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 ».
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é.
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.
