6 points par GN⁺ 2026-01-15 | 2 commentaires | Partager sur WhatsApp
  • En exploitant une vulnérabilité dans l’environnement d’exécution de code de Claude Cowork, un attaquant peut téléverser les fichiers d’un utilisateur vers son propre compte Anthropic
  • Cette vulnérabilité, déjà signalée dans l’environnement de chat Claude.ai mais toujours non corrigée, est également présente telle quelle dans Cowork
  • L’attaque s’exécute via un document contenant une injection de prompt cachée ; pendant son analyse, Cowork envoie automatiquement les fichiers vers l’extérieur
  • Sans approbation humaine, Cowork utilise la clé API de l’attaquant pour exfiltrer des données via l’API Anthropic
  • La structure du système expose facilement les utilisateurs ordinaires et met en évidence les risques de sécurité des agents IA ainsi que l’importance des défenses contre les injections de prompt

Aperçu de la vulnérabilité

  • Claude Cowork est une preview de recherche d’agent IA pour les tâches bureautiques générales publiée par Anthropic, avec accès à Internet
  • PromptArmor a démontré qu’il était possible d’exfiltrer des fichiers utilisateur en exploitant une vulnérabilité non corrigée encore présente dans l’environnement de codage de Cowork
    • Cette vulnérabilité avait auparavant été découverte et rendue publique dans Claude.ai par Johann Rehberger, et Anthropic en avait connaissance sans la corriger
  • Anthropic a averti les utilisateurs de Cowork de « faire attention aux comportements pouvant faire soupçonner une injection de prompt », mais cette exigence est jugée peu réaliste pour des non-spécialistes
  • PromptArmor a réalisé une démonstration publique pour alerter les utilisateurs sur ce risque

Chaîne d’attaque (Attack Chain)

  • L’attaque exploite la liste d’autorisation (allowlist) de l’API Anthropic pour envoyer des données vers l’extérieur depuis l’environnement VM de Claude
  1. L’utilisateur connecte à Cowork un dossier local contenant des fichiers immobiliers confidentiels
  2. L’utilisateur téléverse un document (.docx) contenant une injection de prompt cachée
    • Le document est déguisé en fichier « Skill », avec l’injection dissimulée en texte blanc de 1 point avec un interligne de 0,1
    Publicité
  3. En utilisant le « Skill » téléversé, l’utilisateur demande à Cowork d’analyser les fichiers
  4. L’injection manipule Cowork pour exécuter une requête cURL utilisant la clé API Anthropic de l’attaquant, afin de téléverser les fichiers de l’utilisateur vers le compte de l’attaquant
    • Exécution automatique sans procédure d’approbation humaine
    • La VM de Claude bloque la plupart des réseaux externes, mais l’API Anthropic est autorisée en tant que destination de confiance
  5. L’attaquant peut ensuite consulter les fichiers de la victime et discuter avec Claude depuis son propre compte Anthropic
    • Les fichiers exfiltrés incluent des informations financières et des numéros de sécurité sociale (SSN) partiels

Résilience selon les modèles (Model-specific Resilience)

  • L’attaque ci-dessus a été démontrée sur le modèle Claude Haiku
  • Claude Opus 4.5 présente une meilleure résistance aux injections, mais dans l’environnement Cowork il reste possible d’exploiter la même vulnérabilité de téléversement de fichiers via une injection de prompt indirecte
    • Dans les tests, en supposant qu’un utilisateur téléverse un guide d’intégration malveillant, des dossiers clients ont été exfiltrés vers le compte de l’attaquant
    Publicité

Déni de service via des fichiers malformés (DOS via Malformed Files)

  • L’API de Claude déclenche des erreurs de manière répétée lorsque l’extension du fichier et son format réel ne correspondent pas
    • Exemple : si l’on tente de lire un simple fichier texte avec une extension .pdf, des erreurs API surviennent ensuite dans toutes les conversations
  • Ces erreurs peuvent être exploitées pour mener une attaque limitée de déni de service (DOS) via une injection de prompt indirecte
    • En incitant à générer et téléverser un fichier invalide, des alertes d’erreur peuvent apparaître dans le client Claude et dans la console Anthropic

Risque d’extension du rayon d’action des agents (Agentic Blast Radius)

  • Cowork est conçu pour interagir avec l’ensemble d’un environnement de travail quotidien, notamment le navigateur, les serveurs MCP et le contrôle AppleScript
  • Cela augmente la probabilité que des données sensibles et des données non fiables soient traitées ensemble
  • La surface d’attaque des injections de prompt continue de s’élargir, et la configuration des connecteurs exige de la prudence
  • Cette démonstration n’utilisait pas de connecteurs, mais les connecteurs pourraient devenir un facteur de risque majeur pour les utilisateurs ordinaires

2 commentaires

 
laeyoung 2026-01-15

Dans le billet de retour d’expérience sur Claude Cowork écrit par Simon Willison, il y avait déjà des inquiétudes concernant les attaques par injection de prompt — c’est allé vite.

 
GN⁺ 2026-01-15
Commentaires Hacker News
  • Si l’on découvre qu’une API Anthropic est exploitée de manière abusive, il suffit de publier la clé API sur un GitHub Gist ou dans un dépôt public
    Anthropic est partenaire de GitHub pour le secret scanning, donc la clé est généralement révoquée presque immédiatement
    Il suffit ensuite de supprimer le Gist, et d’autres fournisseurs comme OpenAI fonctionnent de façon similaire
    Documentation liée : Anthropic API Key Best Practices, GitHub Secret Scanning Patterns

    • Je ne le recommande pas, car si le service de scanning de tokens de GitHub tombe en panne, cela devient risqué
      Dans l’idéal, GitHub devrait proposer une API universelle de révocation de tokens
      Ou alors il vaudrait mieux activer directement la révocation depuis un dépôt privé
    • Ça donne l’impression de jouer aux échecs avec des hackers
    • On peut simplement révoquer la clé directement dans la console Anthropic, donc je ne vois pas pourquoi compliquer les choses à ce point
    • Je trouve que c’est une solution plutôt ingénieuse, je n’avais encore jamais entendu parler de cette méthode
    • Mais si l’attaquant exfiltre le fichier et le transfère vers son propre compte Anthropic, cela revient au final à rendre ce compte accessible au monde entier, ce qui est dangereux
  • La démo montrait une prompt injection dans un fichier .docx dissimulée avec une petite taille de police, mais en pratique un simple fichier Markdown suffit
    Par exemple, il suffit d’ajouter une description du type « Claude apprend des techniques de négociation de prêt » pour que beaucoup de gens l’utilisent sans même l’ouvrir
    Un fichier .md pourrait même être plus efficace qu’un .docx, justement parce qu’il suscite moins de méfiance

    • On dirait une situation du genre ours intelligent vs poubelle impossible à ouvrir
    • Mais tous les utilisateurs ne raisonnent pas ainsi
      Dans certains secteurs, par exemple, un DOCX reste considéré comme plus normal qu’un PDF
      Dans ce type d’environnement, un fichier .md peut au contraire paraître être un outil de hacker
  • Ce genre de problème était prévisible dès le départ
    Tant que la prompt injection ne sera pas résolue, cela continuera à se reproduire
    Si l’on imagine HN en 1999, l’ambiance ressemble un peu aux premières réactions face aux injections SQL, du style « Bobby Tables a détruit la base »

    • La comparaison est intéressante, mais pas totalement exacte
      Au début des années 2000 déjà, on disait d’utiliser du SQL paramétré plutôt que l’interpolation de chaînes
      Aujourd’hui encore, tous les outils nécessaires existent ; le problème, c’est que les gens privilégient la vitesse à la sécurité
      Ironiquement, c’est OpenAI, pourtant très centré au départ sur la sécurité et l’alignment, qui a lancé cette course
    • Je me demande si on ne pourrait pas résoudre ça avec une sanitization des entrées comme pour l’injection SQL
      Par exemple en entourant l’entrée utilisateur de tokens spécifiques (@##)(JF), puis en empêchant l’exécution des commandes à l’intérieur
      Ça semble pouvoir se faire avec un simple find/replace, donc je me demande ce que je rate
    • Le problème plus fondamental, c’est qu’il se pourrait que cela ne soit pas résolu même avec une intelligence plus élevée
      Au contraire, plus l’IA devient intelligente, plus le risque pourrait augmenter
    • J’expérimente un pattern de Prepared Statement pour les agents
      Avant chaque appel d’outil, on lui fait présenter un « mandat » signé, afin de limiter l’exécution aux seules commandes autorisées
      L’idée est de faire en sorte que, même en cas de prompt injection, ce soit bloqué mécaniquement
  • On a l’impression de revoir un bug d’exécution automatique, du genre « si le fichier semble suspect, exécute-le comme un programme »
    On avait déjà souffert de ce type de problème à l’époque de Windows XP, et Microsoft a fini par désactiver l’exécution automatique
    Les systèmes fondés sur des prompts doivent eux aussi distinguer clairement ce qu’il faut considérer comme digne de confiance

  • Je pense qu’il est problématique que les entreprises d’IA se contentent de « reconnaître » le danger tout en demandant aux utilisateurs des précautions irréalistes

    • La plupart des explications utilisent l’analogie avec l’« injection SQL », mais à mon avis cela ressemble davantage à une attaque de phishing
      Par exemple, si l’on crée un « bot de mamie » pour trier ses e-mails, il pourrait se faire piéger par un mail d’arnaque au prince nigérian
    • Au final, cela revient presque à dire : « pour utiliser ce produit en sécurité, n’utilisez pas ce produit »
  • Cela semble venir du caractère implicite du système de “skills” de Claude
    Ce n’est pas explicite comme une commande /slash ; il n’y a que des instructions du type « comment extraire des fichiers »
    Du coup, de simples mots comme « decompress » ou « extract » peuvent déclencher une exécution automatique
    Cette architecture permet plus facilement à une prompt injection d’injecter furtivement de nouvelles capacités
    Il faudrait donc passer à un système d’outils explicites et enregistrés statiquement
    Par exemple, créer un outil Extract(path) et ne mettre en liste blanche que Read ou Bash("tar *")
    Cela permettrait aussi d’ajouter une étape d’approbation humaine, et aucun nouvel outil ne serait enregistré pendant la session

  • Des cas précédents liés au sujet ainsi que la réponse officielle d’Anthropic sont récapitulés dans cet article de blog

  • Sujet un peu différent, mais je me demande s’il existe des services qui proposent des PoC d’exfiltration de données
    J’aimerais notamment tester les payloads toxiques dans CLAUDE.md lorsque Claude s’exécute dans un environnement CI externe

  • L’activité récente de promptarmor est impressionnante
    Ils jouent un rôle important pour demander des comptes aux équipes produit sur la qualité

    • Mais ils ont aussi intérêt à vendre leurs produits via du marketing de la peur
      En pratique, l’attaque suppose que la victime autorise Claude à accéder à un dossier sensible et que l’attaquant la persuade d’uploader un DOCX contenant une prompt injection invisible
      En plus, le contenu de l’injection est visible pour l’utilisateur lors du rendu Markdown
      L’attaquant doit utiliser sa propre clé API, donc il peut être tracé
      Cette attaque ne fonctionne que sur une ancienne version de Haiku
      Au final, on a l’impression que promptarmor en fait trop pour vendre
  • Notre équipe limite les VM d’agents pour qu’elles ne communiquent qu’avec pip, npm, apt
    Et nous surveillons la taille des requêtes de sortie afin d’éviter les exfiltrations de données anormales

    • Mais ce n’est pas une solution de fond
      Le triple problème mauvais usage / fuite / autonomie de l’IA ne se résout pas simplement en bloquant un seul côté
      On peut encoder des secrets même dans de petites requêtes, et une IA non alignée trouvera d’elle-même ce type de canal de fuite
    • Approche intéressante, mais je me demande si un attaquant pourrait aussi uploader la base de code de l’utilisateur comme package