← Back to all reports

One Public Share Link Unlocks Full Takeover of Any User's AI Chat History

Reported May 22, 2026
Severity Critical
Platform Web
Vulnerability Class Auth Bypass + IDOR (CWE-287, CWE-639)
Target Type Major US News Publication
Impact Unauth read, plant, and wipe of every AI conversation any user ever had

The Risk

A single public share link from the news site's AI chat product let any stranger read, plant fake messages into, and delete every conversation the original poster ever had with the AI, including private chats that were never shared. No login, no account, no rate limit. Every share link circulated on social media or in a chat app is a permanent key, because the internal user identifier behind it never changes. The content class (free-form chat with an assistant) routinely contains health, financial, family, employer, and political topics, all exposed by one click on a link the user thought was harmless to share.

The Vulnerability

The AI chat backend had two cooperating flaws that together broke the entire authentication model.

First, the unauthenticated share-lookup endpoint returned the original poster's persistent internal user id in its response body. Share links are public by design, so that id was effectively public.

Second, the conversation history and message endpoints accepted that same internal user id as a query parameter and treated it as a full substitute for the session cookie. The server's own error message confirmed it: with neither cookie nor user id, the API returned "Either user cookie authentication information or a uuid must be provided." The two were treated as equivalent forms of authentication.

The Attack

Two browsers were used. The "victim" browser was the researcher's own authenticated test account. The "attacker" browser was a clean profile with no cookies, no login, and no session, simulating any stranger who clicked a public share link.

Leak the user id

The attacker's browser opened the share URL, then read the share id out of the address bar and called the share-lookup endpoint with no cookies. The response returned the owner's persistent internal user id.

Enumerate every conversation, shared or not

Using only that leaked user id, the attacker called the conversation-history endpoint. The server returned the full list of every conversation the victim ever had, including two conversations the victim had explicitly never shared.

Read a private transcript

The attacker fetched the full transcript of a conversation the victim had never shared. The server returned the entire turn-by-turn dialogue, including the victim's original prompt.

Plant a conversation under the victim's identity

An unauthenticated POST to the message endpoint, carrying the victim's user id in the body, created a new conversation that appeared in the victim's own history sidebar, indistinguishable from a message the victim wrote themselves.

Wipe the victim's entire history

The same primitive applied as DELETE to every conversation id returned in step two destroyed the victim's entire stored chat history in a single loop, with no cookie and no interaction on the victim's side. The victim's history sidebar showed the empty-state message after refresh.

Scale

Thirty sequential unauthenticated requests to the history endpoint averaged 172 ms with no rate limit, no captcha, no challenge.

The Impact

  • Total compromise of confidentiality, integrity, and availability of any user's AI chat history, starting from one public share link.
  • Conversations never intended to be shared were fully readable.
  • Planted conversations appear in the victim's own history under their identity, suitable for framing, reputation damage, or content-policy abuse.
  • An entire chat history can be wiped in seconds against any user holding a circulated share link.
  • Share URLs are inherently public (social media, messaging apps, link previews). Every share link ever circulated is a permanent key, because the internal user id does not rotate.
  • Conversation content routinely contains health, financial, location, family, employer, political, and identifying data.

Remediation

  • Stop accepting the internal user id as a substitute for the session cookie. Bind read, write, and delete on conversation history strictly to the authenticated session.
  • Remove the user id from the unauthenticated share-lookup response. A public share link should never disclose the owner's persistent internal identifier.
  • Treat share access as conversation-scoped only. Possession of a share id should grant read on that one conversation, never enumerate the owner's other conversations.
  • Add per-source rate limiting and anomaly detection on history and delete operations.
  • Forensic review of access logs to identify which user ids were probed via the share-lookup endpoint and whether planted or deleted conversations affected real users.
  • Rotate the internal user id scheme so the leaked values lose value, or invalidate all existing share links as part of the fix.