OpenAI March 2023 ChatGPT User Data Exposure Incident

On March 20, 2023, some ChatGPT users opened the app and found conversation titles in their sidebar that they had never written, titles belonging to other people. The sight alone was enough to suggest a problem with how the system kept one person's session walled off from another's, and that instinct turned out to be correct. Most of the public commentary that followed treated the event as a data breach in the conventional sense, the kind involving an intruder who broke in and took something. That framing points readers toward the wrong lesson. It was an ordinary software bug, the kind that exists in dependencies used across the industry, but it got worse because of an internal mistake inside OpenAI's own infrastructure. No outside attacker was needed. Getting this distinction right matters: the fixes that follow from "we were attacked" look nothing like the fixes that follow from "our caching layer had a race condition," and the rest of this piece builds on the second explanation.

How a race condition in a caching library caused connections to return the wrong user's data

The mechanism sits in a piece of software called redis-py, the library OpenAI used to let its Python server talk to Redis. Redis itself handled the caching of user information, Redis Cluster spread that load across multiple machines, and the Python server ran on Asyncio, a framework built to handle many requests at once without blocking. redis-py manages this by pulling connections from a shared pool: a request goes out on one queue, the response comes back on another, and once the exchange finishes, the connection returns to the pool for the next caller to use.

If a request gets canceled midway through that exchange, after it reaches the incoming queue but before its response comes off the outgoing queue, the trouble starts. When that happens, the connection doesn't get cleaned up properly. It goes back into the shared pool still holding data from the canceled request. So the next unrelated request that grabs that same connection can pull out whatever was left behind. Most of the time this produces nothing worse than a server error, because the leftover data doesn't match what the new request expected. But sometimes the data type lines up, and the server hands it over as if it were a legitimate answer, belonging to a completely different user who never asked for it.

This was not a mysterious or random glitch. It was a deterministic failure mode, the kind that occurs reliably once the right sequence of events lines up, and it was serious enough to be formally tracked under a dedicated advisory entry and assigned two separate vulnerability identifiers. The second exists because the first fix didn't fully close the hole, so versions including 4.5.3 and 5.0.0b1 still carried the flaw. The numbering is a paper trail, not the point. A library used to manage shared connections handled cancellation badly, and that single gap in behavior was enough to let one user's data cross into another user's session.

How an internal server change turned a latent bug into an active exposure

A race condition sitting quietly in a dependency is not the same thing as an active exposure affecting real users. For that gap to close, something had to push the rate of canceled requests high enough for the bug to trigger at scale, and that something came from inside OpenAI. At roughly 1 a.m. Pacific time on March 20, the company made a change to its own server that it later said was introduced by mistake. Request cancellations in Redis spiked sharply because of that change, and the overall error rate rose with them.

The two failures only matter together. If you take away the library bug, the server change still causes a spike in errors, but nobody's data leaks across accounts, so it's just a rough few hours of failed requests. Without the server change, the race condition in redis-py would sit at a trigger rate low enough that it might never produce any noticeable effect. Both had to happen at once: an internal operational mistake collided with a latent dependency flaw, and that turned a theoretical weakness into nine hours of real cross-user exposure.

You could argue OpenAI should have caught this earlier, in staging or under deliberate load testing. But race conditions like this depend on precise timing between an async framework, a connection-pooling library, and a distributed cache cluster under cancellation pressure, so they notoriously resist reproduction on demand. Standard test suites are built to catch logic errors and regressions, not to simulate the exact timing collision that has to occur between Asyncio's cancellation handling and redis-py's queue management for this particular fault to appear. That doesn't excuse what followed, but it does explain why a bug like this can sit undetected in widely used software for a long time before an unrelated operational change gives it the conditions it needs to misfire. Once that combination was live, the next question is what was actually sitting within reach during the nine hours it ran.

Data Reachable During the Nine-Hour Window

Conversation titles leaking into the wrong sidebar was the visible symptom, but it was not the most serious thing happening during that window. In the same nine hours, a different subscriber could see partial payment information that belonged to one ChatGPT Plus subscriber. OpenAI's own notification to affected customers stated plainly: "We have no evidence that any customer information was viewed by more than one other ChatGPT user."

Exposure required two fairly specific conditions, and most users never met either one. The first involved opening a subscription confirmation email sent out on March 20 between 1 a.m. and 10 a.m. Pacific time. Some of those emails went to the wrong recipient, and they contained another subscriber's last four card digits. The second involved visiting the "My Account" page and selecting "Manage my subscription" during that same nine-hour stretch, which could surface a different active subscriber's billing details on screen. OpenAI notified the group of Plus subscribers who were active during that window by email, describing what may have been visible to someone else.

Because the trigger conditions were narrow, OpenAI was able to describe the overall risk as low, and based on the evidence available, that description holds up. But narrow conditions don't change what category of data was involved. Billing information, card digits, and account details crossed from one user to another inside a system built to keep those boundaries sealed, and that is what pulled regulators into the story next.

Why Italy Banned ChatGPT

The March 2023 incident did more than produce an apology and a patch. It triggered the first outright ban of a major AI service by a Western data protection authority, and the three years of regulatory activity that followed show how slowly, and how unevenly, GDPR enforcement moves against an AI provider once it starts.

Italy's data protection authority, the Garante, acted within ten days. On 30 March 2023 it ordered OpenAI to stop processing the personal data of Italian users, and it cited the Redis breach alongside separate concerns about the legal basis for processing and the absence of meaningful age verification. It was the first action of its kind taken against a major AI service by a Western regulator. Service was restored to Italian users on 28 April 2023, after OpenAI added an age-declaration step, expanded its privacy notice, introduced opt-out forms for users who didn't want their data used in training, and built in a way for people to request correction of inaccurate information about them. The ban lifted, but the Garante's formal inquiry into the underlying conduct kept going.

Among the grounds the Garante eventually cited in its enforcement action was a straightforward procedural failure: OpenAI had not notified the authority of the March 2023 incident within the 72-hour window GDPR requires for breach notification. Regulators need that deadline so they can respond to incidents while they're still unfolding, not months later, and missing it became one of four separate grounds cited in the case against OpenAI.

The most recent turn in this story arrived on 18 March 2026, when the Court of Rome annulled both the fine and the associated order requiring OpenAI to run a public media campaign. The annulment rested on a jurisdictional question under GDPR's one-stop-shop mechanism, which assigns lead-authority status to a single regulator based on where a company has its main EU establishment. The court did not decide whether OpenAI had actually violated the GDPR. The underlying questions about lawful basis, age verification, and the delayed breach notification remain open, now in the hands of another national authority as the lead regulator. The case illustrates something structural about enforcement against companies that expand their EU presence while under investigation: opening a new establishment mid-case can shift which regulator has authority to decide it, and that shift can stall or unwind years of a national authority's work without ever touching the merits of what that authority found.

The aftershocks reached well beyond Italy. Once the Garante acted, data protection authorities in France, Spain, Poland, and several German state-level bodies opened their own investigations into generative AI companies. The March 2023 breach didn't just produce one regulator's response; it set off a wave of coordinated attention across multiple national authorities, and that attention outlasted the original nine-hour window by years.

How OpenAI Responded

By ordinary standards, OpenAI's response to the breach itself was thorough. The company added redundant checks to confirm that data pulled from the Redis cache actually matched the user requesting it, and it went back through logs programmatically to verify that messages had only reached the correct recipients. It improved its logging so a recurrence would be easier to catch early, and it invested in the robustness and scale of its Redis cluster to cut down on the connection errors that occur under heavy load. OpenAI also said it worked directly with the maintainers of redis-py, providing a patch aimed at resolving the underlying flaw in the library itself.

A month later, OpenAI launched a bug bounty program, and since then it has raised the maximum payout for exceptional, critical findings by a significant margin. Raising that ceiling signals that external security researchers are being treated as a real part of the company's defense, not a formality. The value of that posture is visible in a separate case: around the same time as the Redis incident, researcher Gal Nagli disclosed a different, also caching-related, account-takeover vulnerability, and OpenAI fixed it within two hours of the report reaching them. That is a fast turnaround by any measure, and it suggests the detection side of OpenAI's security process works well once a flaw has been surfaced.

Not every reaction to the bounty program has been positive. Katie Moussouris, founder and CEO of Luta Security, criticized its nondisclosure requirement directly, calling it "shortsighted" and arguing it "does not serve the public greater good, nor does it serve OpenAI." Her critique points at something specific: a bounty structure that keeps findings confidential manages legal and reputational liability efficiently, but it does less for the broader public that has no visibility into what gets found and fixed. A company can respond to an incident competently, patch quickly, and pay researchers well, while still relying on a security model that is fundamentally reactive, one built to catch and fix problems once they appear in logs or user reports rather than to prevent the conditions that produce them. Whether that reactive posture can hold up for infrastructure holding payment data for millions of subscribers is a separate question from whether OpenAI handled March 2023 well, and the final section shows why.

Why This Incident Fits a Broader Pattern

The Redis bug is one of at least four distinct security incidents documented across the company's recent record, and the variety among them shows that no single engineering fix could address all of OpenAI's security failures. Alongside the Redis exposure, there was an internal forum breach that went unreported, a compromise at a third-party analytics vendor that leaked API customer records, and a UI misconfiguration that caused private conversations to be published and indexed in Google search results.

Each of these is a different category of failure. The forum breach is an access-control problem, someone reached data they shouldn't have been able to reach. The Redis bug is a dependency and concurrency problem, baked into how an async system managed shared connections under cancellation. The vendor compromise is a supply-chain problem that started outside OpenAI's own code. The UI misconfiguration is an output-handling problem, where content meant to stay private got exposed through a configuration error in how it was displayed. No single engineering fix addresses all four, because they don't share a root cause. They share only a company and a timeframe.

This pattern is not unique to AI systems as a category. A Christmas Day incident at Steam in 2015 produced a strikingly similar result: a caching bug let users see the personal account data of other users entirely, through a mechanism that mirrors what happened with redis-py and Redis Cluster in 2023. Caching architectures can fail under load and leak data across session boundaries, and that happens as a known, recurring problem across the software industry, not because of how large language models are built or served.

So if you send customer records, source code, or regulated data into AI tools as part of daily work, you can draw a direct lesson from that history. The risk extends beyond a repeat of the specific Redis scenario from March 2023. An access-control gap, a vendor compromise, an output-handling mistake, a concurrency bug in a caching layer, all four categories apply simultaneously, across every AI tool an organization has adopted, and none of them announce themselves in advance.