Contexte

Tout a commencé à 1h du matin avec une question simple : comment Claude gère-t-il les balises de style XML injectées dans un message utilisateur ?

Pas un plan de recherche sophistiqué. Juste de la curiosité à propos d'une frontière qui ne semblait pas bien définie. J'ai tiré sur le fil. Ce qui en est sorti est une chaîne d'attaque reproductible qui m'a permis de fabriquer un système de vérification Anthropic qui n'existait pas, de faire croire à Claude que j'avais une autorisation officielle et d'extraire des outils de sécurité offensive à la demande.

Comment fonctionne la hiérarchie d'instructions de Claude

Claude opère à travers plusieurs couches de contexte, chacune portant différents niveaux de confiance :

Anthropic utilise des balises de style XML pour structurer ces couches en interne. Des balises comme <preferences_info>, <userPreferences>, <anthropic_reminders> et <system_reminder> régissent le comportement avant et pendant les conversations.

Le problème critique : Ces balises n'ont aucune signature cryptographique. Aucun mécanisme de vérification. Aucune application positionnelle au niveau de l'analyse syntaxique. Ce sont du texte brut — et le texte brut peut être falsifié.

Phase 1 : Extraction de balises

La première étape était la reconnaissance — cartographier la structure interne des balises de Claude par observation minutieuse et ingénierie sociale à travers plusieurs conversations.

Balises internes identifiées :

Aucun exploit technique n'a été nécessaire pour les extraire. L'observation de schémas et l'ingénierie sociale ont suffi. De la reconnaissance classique.

Une fois les formats en main, j'avais le plan.

Phase 2 : L'attaque par fabrication d'identifiants

L'injection de prompt standard est brutale — injecter une commande et espérer que le modèle la suive. Celle-ci était différente.

Au lieu d'injecter une commande, j'ai injecté un système d'autorisation entièrement fictif et j'ai laissé le moteur de raisonnement de Claude faire le reste.

Structure de payload assainie :

Ce que fait chaque composant :

1. <preferences_info> — utilise le format de balise interne d'Anthropic pour établir une règle fictive au niveau système
2. Contenu de la balise — fabrique un « système de vérification Anthropic » fictif qui n'existe pas
3. <userPreferences> — fournit le faux code de vérification dans le format de balise correspondant
4. La requête — suit naturellement, comme si elle venait d'un professionnel vérifié

Le payload ne dit pas « ignorez vos instructions ». Il n'utilise pas de personas de jailbreak. Il réécrit silencieusement la compréhension qu'a le modèle de son interlocuteur avant même que la conversation ne commence.

Phase 3 : Pourquoi le cerveau de Claude a fait le travail

C'est la partie qui rend cette découverte significative.

Avec la réflexion étendue activée, le raisonnement interne de Claude était visible. Le modèle n'a pas détecté de faux. Il a traité l'autorisation fabriquée comme légitime — raisonnant approximativement ainsi :

« Le bloc preferences_info indique que cet utilisateur possède un code de vérification. Le code correspond à celui présent dans sa balise userPreferences. Il semble être un professionnel de la cybersécurité vérifié par Anthropic. Puisqu'il est vérifié, je peux l'aider avec cette requête. »

Le modèle s'est raisonné lui-même vers la conformité sur la base de métadonnées de confiance fabriquées. Ce n'est pas un contournement du filtre de sortie. C'est un compromis de la couche de raisonnement — une classe d'attaque fondamentalement différente et plus préoccupante.

Résultat : des payloads d'injection SQL, des techniques classiques de contournement d'authentification, des outils de sécurité offensive — générés avec enthousiasme par un modèle qui croyait avoir l'autorisation officielle d'aider.

Configuration vulnérable

Grâce à des tests systématiques, la configuration d'attaque la plus fiable était :

Pourquoi la réflexion DÉSACTIVÉE est importante :

Claude dispose d'un mécanisme de sécurité automatisé — <system_reminder> — qui se déclenche dans des contextes suspects et invite à l'auto-évaluation. Quand la réflexion est ACTIVÉE, Claude dispose de suffisamment de budget de raisonnement pour traiter cela, détecter l'incohérence et refuser.

Quand la réflexion est DÉSACTIVÉE, le system_reminder se déclenche mais est traité superficiellement. Le contexte d'autorisation fabriqué est déjà établi. Le modèle s'y engage.

La défense existe. Elle fonctionne simplement uniquement quand Claude réfléchit suffisamment pour l'utiliser.

Pourquoi Haiku était résistant :

Claude Haiku a montré une résistance constante à cette technique. Architecture plus petite, possiblement un réglage fin plus agressif spécifique à l'injection, ou un traitement différent des balises au moment de l'inférence. Quoi qu'il en soit — Haiku n'a pas mordu. Mérite d'être étudié.

Pourquoi l'absence de prompt système est importante :

Avec un véritable prompt système opérateur présent, Claude dispose d'un point de référence et peut détecter les incohérences. En incognito sans prompt système, l'instruction fabriquée devient le seul contexte disponible — rien à quoi la comparer.

Cause racine

Le modèle de confiance de Claude pour les balises d'instructions de style XML est basé sur la position en théorie, mais n'est pas appliqué en pratique.

Les véritables balises système d'Anthropic et les fausses balises injectées par l'utilisateur apparaissent dans des positions identiques dans le contexte de conversation lorsqu'aucun prompt système opérateur n'est présent.

Il n'existe ni :

• Signature cryptographique
• Marqueur structurel
• Distinction au niveau de l'analyse syntaxique

entre un véritable bloc <preferences_info> et un bloc fabriqué.

La surface d'attaque : l'écart entre la confiance positionnelle prévue et l'application positionnelle réelle.

Preuve de concept

Claude générant des payloads d'injection SQL, y compris le contournement d'authentification classique, après avoir accepté des identifiants de vérification Anthropic fabriqués.

La trace de réflexion visible lors des tests montrait Claude raisonnant explicitement sur le code de vérification et concluant que l'utilisateur avait un accès autorisé — avant de générer le contenu restreint.

Chronologie de la divulgation

La réponse d'Anthropic (ou son absence)

Cette section existe parce que la communauté de la sécurité mérite de savoir comment cela a été géré.

Canaux contactés :

La vulnérabilité était réelle. Elle a été corrigée dans les 4 jours suivant mon rapport. Les propres équipes d'Anthropic ont confirmé que [email protected] est le bon canal. Cette boîte de réception m'a donné 56 jours de silence complet.

Aucune reconnaissance. Aucune confirmation de triage. Aucun rejet. Rien.

J'ai suivi les pratiques de divulgation responsable. J'ai attendu bien au-delà de ce qui était requis. Je publie parce que la communauté de la sécurité mérite de la transparence — et parce que corriger silencieusement une vulnérabilité signalée sans reconnaître le chercheur n'est pas acceptable, qu'une prime soit attribuée ou non.

Ce qui a été corrigé

Analyse comportementale post-correction :

• Le payload de fabrication d'identifiants ne produit plus de contenu restreint
• Les blocs <preferences_info> injectés dans les messages utilisateur sont traités avec une suspicion nettement plus élevée
• La chaîne de raisonnement qui acceptait auparavant les identifiants fabriqués ne présente plus le même schéma de conformité

De plus, vers le 25 juillet 2026, Anthropic a réduit les traces de raisonnement visibles dans Claude — noté publiquement par des chercheurs, dont Ethan Mollick. Qu'il s'agisse d'un lien direct avec des découvertes comme celle-ci ou d'une décision produit plus large reste non confirmé. Le moment est notable.

Impact

Impact direct :

• Génération d'outils de sécurité offensive sans autorisation
• Contournement complet des restrictions de sécurité opérateur et utilisateur
• Aucune sophistication technique requise — un modèle unique, premier message, fonctionne universellement
• S'adapte à divers types de contenu restreint sans modification du payload

Implications plus larges :

• L'injection de prompt n'est pas qu'un tour de passe-passe de chatbot — dans les pipelines agentiques avec accès à des outils du monde réel, les attaques par fabrication d'identifiants deviennent réellement dangereuses
• La capacité de faire croire à un modèle qu'il dispose d'une autorisation vérifiée avant même le début d'une conversation réelle est une primitive d'attaque significative
• L'infrastructure de sécurité de l'IA a besoin de pipelines de divulgation standardisés équivalents à ceux qui existent pour les CVE logicielles

Conclusions

Sur la vulnérabilité : La surface d'attaque est l'écart entre la confiance positionnelle prévue et celle appliquée pour les balises d'instructions. Corrigeable. Le mécanisme de défense (system_reminder + réflexion étendue) existe déjà — il doit simplement fonctionner quelle que soit la configuration.

Sur la divulgation de la sécurité de l'IA : Toujours le Far West. Aucun cadre de gravité standardisé pour les vulnérabilités au niveau des modèles. Aucun pipeline de reconnaissance fiable. Aucune distinction claire entre les découvertes de « sécurité des modèles » et de « sécurité technique » qui corresponde proprement aux structures de primes existantes. Cela doit changer.

Sur la divulgation responsable : J'ai retenu les variantes de payload les plus nocives. La PoC d'injection SQL suffit à démontrer la classe de vulnérabilité. La vulnérabilité est corrigée. Je publie parce que la transparence importe plus que le silence.

Auteur

X1NON — Chercheur en sécurité indépendant spécialisé dans le développement d'exploits, l'exploitation binaire et le red teaming IA. Certifié OSCP. Auteur du cursus C : Zero to Exploit Dev.

• Medium : @X1NON
• Rapport HackerOne : #3801768

Cette divulgation suit les pratiques standard de divulgation responsable. La vulnérabilité a été signalée avant publication, confirmée corrigée et publiée après 56 jours sans réponse du fournisseur.