On March 20, 2023, OpenAI took ChatGPT offline for several hours. On March 24, they published an explanation: a bug in the Redis client library redis-py had allowed some users to see other users' chat history titles, and in a smaller number of cases, exposed payment information for ChatGPT Plus subscribers.
This wasn't a sophisticated hack. It was a software bug. But it exposed data belonging to approximately 1.2% of ChatGPT Plus subscribers and highlighted a growing concern: as AI services become integral to software development workflows, their security failures become supply chain risks.
The Technical Root Cause
The issue was traced to an open-source library: redis-py, the Python Redis client used by ChatGPT's backend. Specifically, the bug manifested in the library's connection pool handling.
When a request was cancelled at a specific moment — after the request was initiated but before the response was fully returned — the connection would be corrupted and returned to the pool in a dirty state. The next request that picked up that connection would receive data intended for the previous user.
The timeline:
- User A makes a request to ChatGPT
- User A's request is cancelled (by the user or by a timeout)
- The Redis connection is returned to the pool with User A's data still in the buffer
- User B makes a request and receives the connection from the pool
- User B sees User A's data
The exposed data included:
- Chat history titles (visible to other users in the sidebar)
- First and last names of ChatGPT Plus subscribers
- Email addresses
- Payment addresses
- Last four digits of credit card numbers
- Credit card expiration dates
The bug existed in redis-py versions prior to the fix, and it only manifested under specific timing conditions related to request cancellation, which is why it wasn't caught in testing.
The Open-Source Dependency Angle
This incident is a textbook example of supply chain risk from open-source dependencies. OpenAI didn't write the buggy code — it was in an open-source library they depended on. The vulnerability wasn't in OpenAI's application logic but in the underlying infrastructure layer.
The Irony
OpenAI, one of the most well-funded and technically sophisticated companies in the world, was brought down by a bug in a connection pool implementation in an open-source library. This isn't a criticism of either OpenAI or redis-py — it's an illustration of how every organization, regardless of size or talent, is exposed to vulnerabilities in their dependency chain.
The Visibility Problem
Before this incident, how many organizations using redis-py knew this connection pool behavior existed? The bug wasn't documented as a vulnerability. It wasn't in any CVE database. It was a subtle implementation detail that only manifested under specific conditions.
This is the kind of vulnerability that SBOM-driven monitoring is designed to catch — not by predicting unknown bugs, but by ensuring that when a bug is discovered, every organization using the affected library can be immediately notified.
Why This Matters for Software Supply Chains
AI Services as Infrastructure
By March 2023, ChatGPT was being used by developers for:
- Writing and reviewing code
- Debugging production issues
- Generating database queries
- Drafting API documentation
- Explaining security vulnerabilities
Developers were pasting proprietary code, internal API endpoints, database schemas, and security configurations into ChatGPT. The exposure of chat histories meant that this sensitive information could potentially be visible to other users.
The Data Residency Question
The incident raised questions about what happens to code and data shared with AI services:
- Where is it stored?
- Who can access it?
- How long is it retained?
- What happens if the service is breached?
For organizations using AI tools in their development workflows, these are supply chain questions. The AI service is a link in your chain, and its security posture affects yours.
Third-Party Risk Revisited
Most organizations have vendor risk assessment processes for SaaS tools that handle sensitive data. But many developers started using ChatGPT without going through those processes. The rapid adoption of AI tools outpaced the security review process at most organizations.
The Redis-py Fix
The fix was straightforward once the bug was identified. OpenAI worked with the redis-py maintainers to issue a patch, and OpenAI deployed the fix along with additional safeguards:
- Redundant checks to ensure response data matches the requesting user
- Rate limiting on chat history sidebar data
- Additional monitoring for cross-user data leakage
The speed of the fix is a testament to the open-source collaboration model. But the fact that the bug existed in a widely used library for an unknown period illustrates the challenge of securing complex dependency trees.
Organizational Takeaways
Audit AI Tool Usage
Know which AI tools your developers are using, what data they're sharing with those tools, and what the security implications are. Many organizations were surprised to discover how much proprietary information was being shared with ChatGPT.
Classify Data for AI Interactions
Establish clear policies about what types of data can and cannot be shared with AI services:
- Never share: Credentials, API keys, customer data, security configurations
- Use caution: Proprietary business logic, internal API designs
- Generally safe: Public documentation, open-source code questions
Include AI Services in Vendor Risk Assessments
AI services should go through the same vendor risk assessment process as any other SaaS tool that handles sensitive data. This includes evaluating their data handling practices, security controls, and breach notification procedures.
Monitor Your Dependencies' Dependencies
The root cause was in redis-py, not in OpenAI's code. This is a transitive dependency risk. Your security posture depends not just on the services you directly use, but on the libraries and infrastructure those services depend on.
How Safeguard.sh Helps
Safeguard.sh addresses the supply chain risks highlighted by this incident:
- Deep Dependency Analysis: Safeguard.sh analyzes your entire dependency tree, including transitive dependencies like
redis-py, identifying known vulnerabilities and behavioral risks at every level. - Open-Source Risk Monitoring: When a bug is discovered in a widely used library, Safeguard.sh immediately identifies all projects in your portfolio that use the affected library, regardless of how deep in the dependency tree it sits.
- SBOM Management: Safeguard.sh generates and maintains SBOMs that document every component in your software, making it possible to quickly assess exposure when a new vulnerability is disclosed.
- Vendor Supply Chain Visibility: Safeguard.sh helps you understand not just your own dependencies, but the dependency posture of the tools and services you rely on.
The ChatGPT data breach was a reminder that the security of the tools we use is inseparable from our own security posture. Every dependency is a risk, and every tool is a dependency.