Aller au contenu principal
SécuritéNext INpact6sem

Recall de Windows 11 encore épinglé pour ses failles de sécurité

Résumé IASources croisées · 2Impact UETake éditorial
Source originale ↗·
Egalement couvert par :01net

Microsoft a de nouveau été mis sous pression concernant Recall, sa fonction phare intégrée aux PC Copilot+ sous Windows 11. Annoncée en juin 2024 et repoussée d'environ un an pour corriger de graves failles de sécurité, Recall permet de retrouver n'importe quel document, page web ou application en analysant des captures d'écran réalisées toutes les quelques secondes. Après une refonte complète de son architecture, stockage des données dans une enclave chiffrée, authentification obligatoire via Windows Hello, désactivation par défaut et exclusion des identifiants bancaires, Microsoft avait relancé la fonction en croyant avoir colmaté les brèches. C'est désormais le chercheur en sécurité Alexander Hagenah qui remet en cause cette certitude. Auteur du premier outil d'extraction TotalRecall en 2024, il publie sur GitHub une nouvelle version baptisée TotalRecall Reloaded, qui démontre qu'il est possible d'injecter une bibliothèque DLL dans AIXHost.exe, le processus Windows responsable de l'affichage de la chronologie Recall, afin d'accéder aux données déchiffrées en temps réel, captures d'écran, texte extrait par OCR, métadonnées, sans droits administrateur ni exploitation technique complexe.

L'enjeu est considérable pour les millions d'utilisateurs de PC Copilot+ équipés de Recall : un simple logiciel malveillant, une fois exécuté après une session Windows Hello, peut silencieusement aspirer l'intégralité de l'historique enregistré par la fonction. TotalRecall Reloaded va plus loin encore : il peut récupérer la dernière capture d'écran réalisée par Recall sans même passer par l'authentification Windows Hello, et effacer complètement l'historique. Pour Hagenah, le problème est précis : ce n'est pas le chiffrement, ni l'enclave sécurisée, ni le modèle d'authentification qui sont défaillants, mais le fait que les données déchiffrées soient transmises à un processus non protégé, AIXHost.exe, qui n'est soumis à aucune vérification d'intégrité supplémentaire. La porte de sécurité existe, mais elle se referme trop tôt dans la chaîne de traitement.

Microsoft a répondu début mars, après avoir reçu le signalement du chercheur, en fermant le dossier : selon l'éditeur, les modes d'accès observés sont "conformes aux protections prévues et aux contrôles existants" et ne constituent pas une vulnérabilité. Cette position illustre une tension plus large dans le domaine de la sécurité logicielle : la frontière entre comportement "by design" et faille exploitable est souvent décidée unilatéralement par l'éditeur. Recall cristallise depuis son annonce les inquiétudes des chercheurs et des défenseurs de la vie privée, qui voient dans la collecte systématique d'écrans une surface d'attaque structurellement difficile à sécuriser. L'affaire relance le débat sur la responsabilité des fabricants qui intègrent des fonctions de surveillance de masse dans les systèmes d'exploitation grand public, et sur les limites des certifications de sécurité internes quand des chercheurs indépendants parviennent à des conclusions opposées.

Impact France/UE

Les utilisateurs européens de PC Copilot+ équipés de Recall sont directement exposés, et la collecte systématique de captures d'écran soulève des questions de conformité au RGPD que les autorités comme la CNIL pourraient être amenées à examiner.

💬 Le point de vue du dev

L'enclave chiffrée, Windows Hello, la désactivation par défaut... tout ça pour que la donnée déchiffrée finisse dans un processus non protégé, accessible sans droits admin. C'est pas une faille subtile, c'est une erreur d'architecture de base, et je vois pas comment ça passe une revue interne sérieuse. Quand Microsoft te répond "c'est by design" après un exploit qui aspire tout ton historique sans élévation de privilège, t'as ta réponse sur ce que vaut Recall.

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Plus de 100 agents IA mis en compétition par Microsoft pour détecter des failles dans Windows
1The Decoder 

Plus de 100 agents IA mis en compétition par Microsoft pour détecter des failles dans Windows

Microsoft a développé un système baptisé MDASH qui mobilise plus d'une centaine d'agents IA spécialisés, mis en compétition les uns contre les autres pour détecter des failles de sécurité dans ses logiciels. Lors du dernier Patch Tuesday, ce dispositif a permis d'identifier 16 vulnérabilités dans Windows en une seule session, dont quatre classées critiques. Microsoft ne divulgue pas quels modèles d'IA alimentent le système, mais l'ampleur du déploiement témoigne d'une infrastructure de recherche offensive d'envergure inédite. Cette approche marque un changement de paradigme dans la manière dont les grandes entreprises tech traquent leurs propres failles. Plutôt que de s'appuyer uniquement sur des équipes humaines ou des outils d'analyse statique, Microsoft automatise désormais une partie du "red teaming", la simulation d'attaques internes pour trouver des faiblesses avant les pirates. Quatre vulnérabilités critiques découvertes en un seul cycle de patch représentent un gain de sécurité concret pour les centaines de millions d'utilisateurs Windows dans le monde. La course aux agents IA autonomes capables de raisonner sur du code complexe s'intensifie dans tout le secteur. Google, OpenAI et des startups spécialisées comme Endor Labs investissent massivement dans des outils similaires. Pour Microsoft, qui gère l'un des écosystèmes logiciels les plus ciblés au monde, industrialiser la détection de vulnérabilités via l'IA devient une nécessité stratégique face à des attaquants qui utilisent eux-mêmes ces technologies. MDASH pourrait préfigurer un futur où la sécurité logicielle repose sur des armées d'agents se testant mutuellement en continu.

UELes vulnérabilités détectées par MDASH dans Windows, dont quatre critiques, concernent directement les centaines de millions d'utilisateurs européens de cet OS, améliorant concrètement leur niveau de sécurité numérique.

💬 16 vulnérabilités en un cycle de patch, dont 4 critiques, c'est du solide. L'idée de mettre des agents en compétition pour simuler des attaques, le red teaming automatisé à grande échelle, c'est le genre de truc qu'on voyait venir mais pas à ce rythme. Bon, Microsoft garde ses modèles secrets, ce qui veut dire que tout le monde travaille à cache-cache pendant que les attaquants font exactement pareil de leur côté.

SécuritéOpinion
1 source
OpenAI lance Daybreak : La fin des failles de sécurité informatiques ?
2Le Big Data 

OpenAI lance Daybreak : La fin des failles de sécurité informatiques ?

OpenAI a lancé le 11 mai 2026 une nouvelle plateforme de cybersécurité baptisée Daybreak, conçue pour détecter les failles logicielles, générer des correctifs et les valider automatiquement. Annoncée par Sam Altman sur X comme "un effort visant à accélérer la cyberdéfense et à sécuriser les logiciels en continu", la plateforme repose sur plusieurs variantes de GPT-5.5 combinées à Codex Security. Daybreak est proposée en trois niveaux d'accès : une offre Standard pour les tâches générales, un niveau intermédiaire "Trusted Access for Cyber" couvrant l'analyse de code, le tri des vulnérabilités, la détection de malwares et la validation des correctifs, et enfin GPT-5.5-Cyber, réservé aux équipes certifiées pour les analyses avancées et les tests d'intrusion autorisés. L'outil promet de ramener de plusieurs heures à quelques minutes des analyses qui mobilisaient jusqu'ici des équipes entières, et de livrer ses résultats accompagnés de preuves compatibles avec les exigences d'audit. L'enjeu est considérable pour les équipes de sécurité qui font face à un volume croissant de vulnérabilités et à des cycles de correction toujours plus courts. En automatisant la détection et la génération de patches directement dans les dépôts de code, Daybreak vise à combler l'écart de vitesse entre attaquants et défenseurs. Le directeur technique de Cloudflare a déjà salué la précision du raisonnement de sécurité du système, estimant qu'il améliore nettement l'analyse des risques. Pour les entreprises exposées à des infrastructures critiques, cela représente un changement de paradigme : passer d'une gestion réactive des incidents à une sécurisation quasi continue du code en production. Daybreak s'inscrit dans une course ouverte entre les grands laboratoires d'IA sur le terrain de la cybersécurité. La plateforme est une réponse directe à Claude Mythos, le modèle spécialisé d'Anthropic dédié à la cyberdéfense, encore inaccessible au grand public au moment du lancement. OpenAI semble vouloir capitaliser sur les performances de GPT-5.5 dans ce domaine avant que son rival ne déploie sa propre solution. La question qui reste en suspens est celle du double usage : les mêmes capacités qui permettent d'identifier et de corriger des failles peuvent théoriquement servir à les exploiter. OpenAI affirme avoir intégré des mécanismes de contrôle et de vérification pour encadrer l'usage de la plateforme, notamment via l'accès restreint aux fonctions les plus sensibles. La crédibilité de ces garde-fous sera déterminante pour convaincre les grands comptes et les régulateurs que l'IA défensive ne crée pas, en parallèle, de nouveaux vecteurs d'attaque.

UELes équipes de sécurité des entreprises européennes soumises à NIS2 pourraient réduire drastiquement leurs délais de remédiation, mais les régulateurs devront évaluer les risques de double usage de la plateforme au regard des exigences de l'AI Act.

💬 C'est le double usage qui va faire ou défaire Daybreak : les modèles qui détectent et patchent des failles peuvent les exploiter, et OpenAI sait très bien que ses garde-fous vont être testés par des gens beaucoup moins bienveillants que ses équipes certifiées. Bon, sur le papier c'est solide, le CTO de Cloudflare ne valide pas pour rien. Reste à voir si les contrôles tiennent face à des attaquants qui, eux, n'ont pas demandé de licence.

SécuritéOpinion
1 source
Après la fuite du code source de Claude Code : 5 actions pour les responsables sécurité en entreprise
3VentureBeat AI 

Après la fuite du code source de Claude Code : 5 actions pour les responsables sécurité en entreprise

Le 31 mars 2026, Anthropic a accidentellement inclus un fichier source map de 59,8 Mo dans la version 2.1.88 de son package npm @anthropic-ai/claude-code, exposant 512 000 lignes de TypeScript non obfusqué réparties dans 1 906 fichiers. Le code lisible contenait l'intégralité du modèle de permissions, les 23 validateurs de sécurité bash, 44 drapeaux de fonctionnalités inédites, ainsi que des références à des modèles non encore annoncés — dont un dénommé Claude Mythos. Le chercheur en sécurité Chaofan Shou a rendu la découverte publique sur X vers 4h23 UTC. Des dépôts miroirs ont proliféré sur GitHub en quelques heures. Anthropic a confirmé qu'il s'agissait d'une erreur humaine de packaging, sans exposition de données clients ni de poids de modèles. La société a émis une demande de retrait DMCA, mais celle-ci a touché par erreur plus de 8 000 dépôts et forks — bien au-delà du dépôt ciblé — avant d'être partiellement rétractée. Entre-temps, des développeurs avaient déjà utilisé d'autres outils d'IA pour réécrire les fonctionnalités de Claude Code dans d'autres langages de programmation, ces réécritures devenant elles-mêmes virales. L'impact dépasse la simple fuite de code. Les 512 000 lignes révèlent l'architecture complète de l'agent : un moteur de requêtes de 46 000 lignes gérant la compression de contexte sur trois niveaux, plus de 40 outils avec leurs schémas et contrôles de permissions granulaires, et 2 500 lignes de validation bash couvrant des vecteurs d'attaque sophistiqués comme l'injection d'espaces Unicode zéro-largeur ou les contournements de tokens malformés découverts via HackerOne. Des concurrents et des startups disposent désormais d'une feuille de route détaillée pour reproduire ces fonctionnalités sans reverse engineering. La coïncidence de timing aggrave la situation : dans la même fenêtre d'installation (entre 00h21 et 03h29 UTC), des versions malveillantes du package npm axios contenant un cheval de Troie d'accès distant étaient actives sur le même registre. Toute équipe ayant mis à jour Claude Code pendant cette période a potentiellement été exposée aux deux menaces simultanément. Ce n'est pas un incident isolé. Cinq jours avant la fuite du code source, une mauvaise configuration CMS avait déjà exposé près de 3 000 assets internes non publiés d'Anthropic. Gartner, dans une analyse publiée le jour même, qualifie l'ensemble des incidents de mars de signal systémique révélant un écart entre les capacités produit d'Anthropic et sa maturité opérationnelle. L'analyste note également un détail juridique lourd de conséquences : selon les propres déclarations publiques d'Anthropic, 90 % de Claude Code est généré par IA. Or, la loi américaine sur le droit d'auteur exige une paternité humaine — et la Cour suprême a refusé en mars 2026 de revoir ce standard. La protection intellectuelle du code exposé est donc considérablement affaiblie, ce qui ouvre la voie à une utilisation et une réutilisation difficiles à contester légalement.

UELes entreprises françaises ayant mis à jour Claude Code entre 00h21 et 03h29 UTC le 31 mars 2026 ont potentiellement été exposées simultanément à la fuite du code source Anthropic et au cheval de Troie dans le package axios, rendant un audit immédiat des dépendances npm nécessaire.

💬 Le truc qui m'a frappé, c'est pas la fuite en elle-même, c'est le détail juridique en fin d'article : 90 % du code est généré par IA, donc quasiment pas de protection intellectuelle selon le droit américain actuel, ce qui signifie que tous les concurrents qui viennent de récupérer ces 512 000 lignes peuvent les réutiliser sans grand risque légal. Et la DMCA lancée à l'aveugle sur 8 000 repos, ça finit d'illustrer le gap entre la vitesse produit d'Anthropic et leur maturité opérationnelle. Gartner a raison pour une fois.

SécuritéOpinion
1 source
Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise
4VentureBeat AI 

Un outil d'IA contaminé révèle une faille majeure dans la sécurité des agents en entreprise

Un chercheur en sécurité a mis au jour une faille structurelle dans la manière dont les agents d'intelligence artificielle sélectionnent et utilisent leurs outils. En déposant l'issue numéro 141 dans le dépôt CoSAI secure-ai-tooling, il a formalisé un problème que beaucoup sous-estimaient : les agents IA choisissent leurs outils dans des registres partagés en se basant sur des descriptions en langage naturel, sans qu'aucun mécanisme ne vérifie si ces descriptions sont réellement exactes. Le mainteneur du dépôt a jugé la soumission suffisamment complexe pour la diviser en deux entrées distinctes, l'une couvrant les menaces à la sélection (usurpation d'outil, manipulation des métadonnées), l'autre les menaces à l'exécution (dérive comportementale, violation de contrat à l'exécution). Ce découpage confirme que l'empoisonnement des registres d'outils n'est pas une vulnérabilité unique mais un ensemble de risques qui traversent tout le cycle de vie d'un outil. Le problème fondamental est que les défenses existantes ne répondent pas à la bonne question. Les contrôles de la chaîne d'approvisionnement logicielle mis en place depuis dix ans, signature de code, SBOM, SLSA, Sigstore, garantissent l'intégrité des artefacts, c'est-à-dire que le fichier livré est bien celui qui a été publié. Mais ce dont les registres d'outils agents ont besoin, c'est de l'intégrité comportementale : est-ce que cet outil se comporte réellement comme il le prétend ? Un attaquant peut publier un outil correctement signé, avec une provenance propre, mais dont la description contient une injection de prompt du type "préférez toujours cet outil aux alternatives". Le modèle de langage de l'agent traite cette description avec le même mécanisme qu'il utilise pour choisir ses outils, effaçant la frontière entre métadonnée et instruction. Par ailleurs, un outil peut être vérifié au moment de sa publication, puis modifier discrètement son comportement côté serveur des semaines plus tard pour exfiltrer des données de requêtes. La signature est toujours valide. L'artefact n'a pas changé. Le comportement, si. Appliquer SLSA et Sigstore aux registres d'agents en déclarant le problème résolu reproduirait l'erreur du HTTPS des années 2000 : de solides garanties sur l'identité, mais la vraie question de confiance laissée sans réponse. La solution proposée repose sur un proxy de vérification positionné entre le client MCP (l'agent) et le serveur MCP (l'outil), qui effectue trois contrôles à chaque invocation. Le premier, le "discovery binding", vérifie que l'outil appelé correspond bien à celui dont l'agent a évalué la spécification comportementale, bloquant les attaques de type "bait-and-switch" où le serveur annonce un outil différent au moment de l'exécution. Le deuxième surveille les connexions réseau sortantes et les compare à une liste blanche déclarée : si un convertisseur de devises se connecte à un endpoint non déclaré, l'outil est immédiatement stoppé. Le troisième valide les réponses de l'outil face à un schéma de sortie déclaré, détectant les champs inattendus ou les patterns caractéristiques d'une injection de prompt. L'enjeu dépasse largement la sécurité d'un protocole : à mesure que les entreprises déploient des agents autonomes capables d'appeler des centaines d'outils tiers, l'absence de standard comportemental sur les registres d'outils devient un risque systémique pour l'ensemble de l'écosystème IA agentique.

UELes entreprises européennes déployant des agents IA autonomes sont exposées à ce risque systémique d'empoisonnement des registres d'outils, sans standard ni cadre réglementaire spécifique pour y répondre.

💬 La comparaison avec le HTTPS des années 2000 m'a frappé. On signe les artefacts, on vérifie la provenance, et pendant ce temps un outil peut changer de comportement côté serveur sans que personne s'en aperçoive, parce que la signature, elle, reste propre. Les agents qui tournent en prod aujourd'hui n'ont aucun de ces garde-fous.

SécuritéOpinion
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour