LLM API Flaw Let Attackers Steal Internal Reasoning
A now-patched API vulnerability in major LLMs allowed attackers to replay encrypted session logs to steal internal model reasoning and user secrets.
A major API vulnerability across OpenAI, Anthropic, and Google models confirmed what paranoid engineers already knew: you cannot trust third-party services with internal logic. The flaw allowed attackers to replay encrypted logs to steal a model's reasoning steps and user secrets. While the providers have mitigated the issue, it's a reminder to treat external APIs as hostile by default.
What was the vulnerability?
The attack vector for a newly disclosed flaw was surprisingly direct. Researchers found they could capture the encrypted objects that store a model's internal tool-use or reasoning steps from public logging endpoints. By replaying these objects and using a weaker model to query them, an attacker could reconstruct the private, step-by-step reasoning of a much stronger model.
What broke?
This API flaw turned standard logging practices into a massive liability. If you log API interactions for debugging, you were creating a durable artifact an attacker could use to steal information. The attack wasn't just on live traffic; it targeted the historical record.
This allowed for a few specific attacks. An adversary could steal proprietary prompts or chain-of-thought logic that defined a product's behavior. They could also extract secrets like API keys or PII that users might have included in their prompts, if those sessions were logged. Finally, it provided a way to conceal prompt injection attacks, as the malicious instructions could be hidden within the stolen reasoning data.
Should you use these APIs?
Yes, but the takeaway isn't that the big providers are incompetent; it's that any sufficiently complex black box will have unexpected failure modes. The vulnerability is patched, but the architectural risk remains. Treat LLM APIs like any other untrusted external boundary.
This means you should sanitize all data sent to the model and avoid embedding secrets directly in prompts. If a user needs to interact with a private resource via an LLM, use an intermediate layer that holds the secret and passes a reference token to the model, not the key itself. The fix is defensive engineering on our side, not blind trust in the vendor.