Cross-Tenant IDOR in AI Chat History Endpoint Allows Developers to Read Other Developers’ Conversations
A public developer AI chat REST endpoint stored conversation history under a client-visible conversation_id but did not verify that the supplied conversation_id belonged to the API key making the request. Any self-serve developer with an API key and a known or leaked conversation_id could retrieve another tenant’s AI chat history, including sensitive prompts and reference data.
Vulnerability: Insecure Direct Object Reference / Broken Object Level Authorization (CWE-639) · Severity: Medium — cross-tenant confidentiality impact, bounded by the need to know a high-entropy 22-character conversation_id with no enumeration or prediction path described.
Summary
The public developer AI chat REST endpoint at POST https://[REDACTED-HOST]/ai/conversations/v2 persisted conversation history keyed by a client-visible conversation_id. The server accepted a caller-supplied conversation_id and loaded the associated conversation history without verifying that the conversation_id belonged to the API key presented in the Authorization header.
As a result, any ordinary self-serve developer API key could retrieve another developer’s AI chat conversation history by supplying the victim’s conversation_id. The leaked history could include whatever the victim entered into prompts, including PII, business intelligence, project details, customer details, locations, internal references, reference tags, or other sensitive context.
The original report classified the issue as a real cross-tenant authorization break, but bounded severity at Medium because the conversation_id was described as a 22-character base64url, 128-bit random token with no timestamp, no counter, and no listing endpoint. Exploitation therefore required a known or leaked conversation_id, for example from logs, sharing, screenshots, or a referer.