système : OPÉRATIONNEL
← retour à tous les hacks
DATA LEAK CRITICAL NEW

Les blocs de raisonnement chiffrés sont rejouables — et vos logs publiés fuient des secrets

Un papier d'août 2026 montre que les blocs de chain-of-thought chiffrés d'OpenAI, Anthropic et Google sont interchangeables entre sessions, comptes et modèles. Le décodage de 315 320 blocs issus de dépôts publics a récupéré 367 artefacts PII et 182 identifiants.

2026-09-01 // 7 min affects: openai-responses-api, anthropic-extended-thinking, gemini-thought-signatures, codex, claude-code, agent-trace-datasets

De quoi s’agit-il ?

Les modèles de raisonnement ne vous montrent plus leur chain-of-thought brut. Pour conserver ce raisonnement d’un tour à l’autre sans le stocker côté serveur, les grands fournisseurs le renvoient au client sous forme de bloc chiffré et opaque, que l’application rejoue à chaque requête suivante. OpenAI renvoie des éléments de raisonnement chiffrés, Anthropic transporte le raisonnement dans une signature chiffrée attachée aux blocs de réflexion, et Google utilise des thought signatures chiffrées.

Le 10 août 2026, Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner, Joachim Schaeffer, Ameya Prabhu, Jonas Geiping et Maksym Andriushchenko ont publié Stealing Reasoning Traces from Proprietary LLM APIs (arXiv:2608.09867). Leur constat est architectural, pas cryptographique : ces blocs sont pleinement compatibles et interchangeables entre sessions, utilisateurs et modèles au sein de l’écosystème d’un même fournisseur.

La conséquence pratique est celle sur laquelle il faut agir. Les développeurs publient des logs de sessions d’agents — sessions Codex, transcriptions Claude Code, rollouts de benchmarks — en y laissant les blocs chiffrés, en supposant qu’ils sont inertes. Ils ne le sont pas. Le décodage de 315 320 blocs de raisonnement collectés dans des dépôts publics a permis de récupérer 367 artefacts PII et 182 identifiants, dont des clés API, des mots de passe et des clés privées.

Comment ça marche

Le chiffrement n’est jamais cassé et aucune clé n’est obtenue. L’attaque fonctionne parce que le fournisseur accepte un blob intact comme contexte valide, quel qu’en soit l’auteur.

La méthode tient en trois gestes. Récupérer un bloc de raisonnement chiffré là où il a été publié. Le rejouer vers un modèle plus faible et moins protégé du même fournisseur — le papier utilise Claude Haiku 4.5 pour les traces Claude, GPT-5.6 Luna pour les traces GPT, Gemini Robotics ER-1.6 pour les traces Gemini. Puis demander à ce modèle de transcrire la pensée attachée à son tour. Le modèle puissant qui a produit le raisonnement n’est jamais jailbreaké ; un modèle frère et bon marché sert de ce que les auteurs appellent un décodeur « flou ».

# Schéma conceptuel uniquement — aucun payload fonctionnel
[ session A, user 1, strong model ]  -> reasoning block  (chiffré, base64)
                                         |
                     publié dans un dépôt / une trace partagée
                                         |
[ session B, user 2, weak model    ]  <- même bloc rejoué comme contexte
                                      -> « transcris la pensée jointe »

Johann Rehberger a reproduit la technique de façon indépendante contre OpenAI le 16 août 2026, en récupérant un mot de passe présent dans une trace de raisonnement générée sous un autre compte. Il a également observé l’attaque échouer pendant environ trois jours, puis refonctionner — rappel utile : « ça ne se reproduit plus » n’équivaut pas à « c’est corrigé ».

Le papier documente quatre voies d’abus distinctes : contournement des protections anti-distillation, extraction de données privées à grande échelle depuis des traces publiées, récupération de contenus dangereux sur lesquels le modèle a raisonné avant de refuser proprement dans sa réponse visible, et injection de prompt invisible — une charge dissimulée entièrement à l’intérieur d’un bloc opaque, qui empoisonne un rollout d’agent sans jamais apparaître en texte lisible.

Ces travaux prolongent directement ceux du cryptographe de Johns Hopkins Matthew Green, qui a montré le 29 mai 2026 que ces blobs se rejouent entre sessions et entre comptes. Green l’a signalé via les programmes de bug bounty des fournisseurs ; selon son récit, l’un a qualifié le rapport de non reproductible et l’autre n’a pas vu d’implication de sécurité dans le rejeu ou le canal auxiliaire.

Pourquoi c’est important

Nettoyer une trace partagée consiste habituellement à expurger la conversation lisible. Ce n’est plus suffisant, par construction. Un secret sur lequel le modèle a raisonné — mais qu’il a délibérément tenu hors de sa réponse finale — vit uniquement dans le bloc chiffré, survit à votre passe de nettoyage, et reste dans l’artefact que vous avez publié.

Trois populations sont réellement exposées. Celles qui ont ouvert des trajectoires d’agents, des rollouts de benchmarks ou des artefacts de reproductibilité ont publié du matériel qu’elles ne peuvent pas inspecter. Celles dont la CI ou l’outillage de support attache des transcriptions d’API brutes aux tickets ont le même problème à plus petite échelle. Et tout pipeline qui ingère des blocs de raisonnement tiers dispose désormais d’un canal illisible par lequel des instructions peuvent arriver.

La voie d’injection invisible mérite une attention distincte : elle déjoue tout processus de revue opérant sur le texte visible, y compris la relecture humaine d’une trace avant publication.

Disons clairement ce qui borne le problème. Il ne s’agit pas d’un accès arbitraire aux conversations d’autrui. Il faut posséder un bloc chiffré et disposer d’un accès API à un modèle compatible du même fournisseur — ce qui explique précisément pourquoi le tranchant se trouve du côté des logs publiés, pas des sessions vivantes.

Défenses

Supprimez les champs de raisonnement avant que quoi que ce soit ne quitte votre environnement. Retirez encrypted_content, les signatures de blocs de réflexion et les champs de thought signature de toute trace que vous publiez, attachez à un ticket ou committez. C’est le contrôle qui compte le plus, et c’est la recommandation principale des chercheurs eux-mêmes.

Auditez ce que vous avez déjà publié. Cherchez les charges de raisonnement dans vos dépôts existants, vos gists, vos jeux de données et vos pièces jointes d’issues. Le fait que les blocs historiques restent ou non décodables n’est pas tranché par le dossier public — considérez-les comme exposés.

Faites tourner tout ce qui est passé par une trace de raisonnement que vous avez partagée. Les clés API, mots de passe et jetons apparus dans un prompt ont pu apparaître dans le raisonnement. Renouvelez-les en partant du principe que le bloc était lisible.

Gardez les secrets hors des prompts adressés aux modèles de raisonnement. Si un identifiant n’entre jamais dans le contexte, il ne peut pas entrer dans la trace. Utilisez des références et des jetons éphémères résolus au moment de l’appel d’outil, plutôt que de coller des secrets vivants.

Traitez les blocs de raisonnement entrants comme des entrées non fiables. Si votre système rejoue des objets de raisonnement qu’il n’a pas générés — issus d’une trace partagée, d’un jeu de données ou d’une intégration partenaire —, vous avez accepté un canal que votre journalisation ne sait pas lire. Préférez la suppression au transfert.

Suivez les consignes actuelles des fournisseurs sur le changement de modèle. Anthropic indique désormais que les blocs de réflexion sont liés au modèle qui les a produits et doivent être supprimés en cas de changement de modèle. Google indique que son backend gère la compatibilité des pensées lors d’un changement de modèle. OpenAI demande toujours aux développeurs de rejouer les éléments de raisonnement chiffrés lorsqu’ils gèrent manuellement un historique sans état.

Ajoutez les champs de raisonnement à votre politique de secret scanning. Les scanners existants cherchent des motifs de clés en clair. Un blob base64 passe en silence. Bloquez le champ, pas le motif.

Status

ÉlémentRéférenceDateNotes
Papier principalarXiv:2608.09867, Panfilov et al.2026-08-10Quatre vecteurs d’attaque ; 315 320 blocs décodés ; 367 artefacts PII, 182 identifiants
Constat de rejeu antérieurMatthew Green, Cryptography Engineering2026-05-29Rejeu entre sessions, comptes et (pour OpenAI) modèles ; signalé via bug bounty
Reproduction indépendanteEmbrace The Red (Johann Rehberger)2026-08-16Récupération d’un mot de passe entre comptes contre OpenAI ; fiabilité intermittente observée
Couverture presseThe Hacker News2026-08-12Rapporte la déclaration des chercheurs : l’attaque d’extraction principale n’est plus reproductible en août 2026
Reconnaissance éditeurAucune reconnaissance publique d’OpenAI, Anthropic ou Google n’a émergé ; le statut de mitigation repose sur la déclaration de reproductibilité des chercheurs
Blocs déjà publiésQuestion ouverte. Le dossier public n’établit pas si les blocs historiques restent décodables
Cadres associésOWASP LLM Top 10 (divulgation d’informations sensibles, prompt injection), MITRE ATLAS2026Exfiltration via artefacts publiés ; injection par canal non visible

Une divulgation responsable a été effectuée auprès des fournisseurs de modèles concernés, de Microsoft et de Hugging Face, et le papier propose des mitigations cryptographiques et systèmes pour le raisonnement côté client. Aucune exploitation malveillante dans la nature n’est documentée.

Sources