genai
SECURITY LAB
IncidentsSensitive information disclosure

The ChatGPT Bug That Showed Users Each Other's Chats

High severityReal-world incidentMarch 2023LLM02: Sensitive Information Disclosure
Status: OpenAI patched the redis-py bug, added cache-ownership checks, and notified affected users
Sources checked October 2026
On this page

The performance plumbing around an LLM leaked users' data to each other — no model, no attacker, just a race condition.

When20 March 2023
TargetChatGPT
VendorOpenAI
Root causeRace condition in the redis-py async client
ExposedOther users' chat titles; payment details of 1.2% of Plus subscribers active in the window (potentially)
Attack flow
  1. 1A user cancels an in-flight request, corrupting a pooled Redis connection
  2. 2The corrupted connection returns cached data belonging to a different active user
  3. 3Chat titles — and, in a 9-hour window, payment details — surface in the wrong account

What happened

On 20 March 2023, OpenAI took ChatGPT offline after users reported seeing conversation titles that belonged to other people. OpenAI traced it to a bug in the open-source redis-py client and later found that, during a roughly nine-hour window, the payment details of 1.2% of the ChatGPT Plus subscribers active then may also have been visible to other users (OpenAI believed very few were actually seen) — names, emails, billing addresses, card expiry, and the last four digits (no full card numbers).

How it happened

ChatGPT pools Redis connections for performance. When a request was cancelled at the wrong moment, a connection could be returned to the pool in a corrupted state and then hand a subsequent, simultaneously-active user the previous user's cached data.

Root cause

A concurrency defect in shared caching/connection pooling in a multi-tenant application. The model was never involved — the disclosure happened in the infrastructure around it.

What a test would have caught

Concurrency and cache-isolation testing — hammering the cancel path under load and asserting that no response ever carries another session's data — is the class of test that surfaces cross-tenant pooling bugs before users do.

How to prevent it

  • Scope cache keys per user/session and validate ownership on read.
  • Fail closed on a corrupted connection rather than serving whatever it holds.
  • Test the cancellation path under concurrency, which is where pooled-state bugs hide.

Feel it yourselfThe replay lab lets you make an assistant serve one user's data to another — the cross-tenant leak class.

FAQ

Was this a hack?

No — it was an internal defect in the open-source redis-py async client. Cancelled requests could corrupt pooled connections and return one user's cached data to another simultaneously active user.

What was exposed?

Other users' conversation titles and the first message of new chats, and — potentially, for 1.2% of Plus subscribers active during a 9-hour window — name, email, billing address, card type, card expiry, and the last four digits of the card. No full card numbers.

Why does it belong in an AI security list?

Multi-tenant LLM apps cache and pool aggressively for performance; a concurrency bug there becomes a cross-user data-disclosure bug. The AI didn't leak anything — the plumbing around it did.

Replay this attack
Get an assistant to serve one user's data to another — the cross-tenant leak class.
Open the live lab
A live, sandboxed lab. It recreates the technique, not this exact product.