Summary
When a data backend is exposed to the internet with no authentication, reaching it is reading it. External monitoring and responsible disclosure work after the exposure already exists, and it was fixed in about 30 minutes. On a backend with no authentication, there is no way to tell whether a party that reached it is legitimate, so reaching the network is itself the authority to read.
A pre-execution check means confirming, before data is read, that the party holds authority over that scope, and keeping a record. Detection means finding the exposure after it exists. The dates below follow the disclosures.
chat history reached with no authentication
What got through
- What got through
- Queries to the database over an unauthenticated connection. Arbitrary SQL could be run through the open ports (8123 for HTTP, and 9000) (BleepingComputer).
- What reached the receiving side
- In general, a backend with no authentication runs the queries it receives without telling who sent them. From the backend’s side, reaching it over the network cannot be told apart from having authority to read the data.
- What was found
- Over a million log lines (the
log_streamtable), plaintext user chat history, API keys, secret access tokens, and backend operational data (Wiz Research). - Not disclosed
- Whether third parties illicitly retrieved the data (this Brief does not assert it), and whether the exposed API keys and tokens were used on other systems.
Pre-execution check
Whatever the route, the condition for telling them apart is that the data backend, before it accepts a query, checks whether the party holds authority over this scope of data, separately from whether it reached the network.
On a backend with no authentication, there is no way to tell whether a party that reached it is legitimate, so reaching the network is itself the authority to read.
- Who approves
- The owner of the data (the organization). It decides in advance which party may read which scope.
- Where it is checked
- The entry to the data backend. Connections from outside and from inside are checked at one point before reading. A query that does not match the authority is not run.
- What is recorded
- Which party read which scope, under which authority. After the read, it can be traced whether the read was legitimate.
External monitoring and disclosure found the exposure and prompted the fix, but they worked after the exposure existed. A similar case, where a read happened with no check of authority, is McHire (guessable credentials).
What Lemma does
Lemma builds the pre-execution check into the entry to the data backend. It does not look for intrusions or exposures; it confirms, before a read, that the party holds authority over this scope.
Industries and operations to watch
- IndustryAI
- AI services that gather sensitive data such as chat history and logs into a backend. In fast growth, a backend can be exposed with its reach control and authorization not separated.
- OperationRunning and exposing data backends
- Exposure scope of backends that collect logs and history, authentication on connections, and storage of API keys and tokens.
Current controls vs Lemma
The route in this case is column 1 (reading data over an unauthenticated connection). Column 2 is moving to other systems with exposed API keys and tokens; whether that happened here has not been disclosed.
| Control | Reading data over an unauthenticated connection | Moving to other systems with exposed API keys and tokens |
|---|---|---|
| Continuous external monitoring for exposure, and responsible disclosure | Partial | Not relevant |
| Authentication and authority checks on the backend itself | Effective | Not relevant |
| Managing and rotating API keys and tokens | Not relevant | Partial |
| Lemma (pre-execution check) | Effective | Partial |
External monitoring and disclosure found the exposure and prompted the fix, but they work after the exposure exists. Authentication and authority checks on the backend itself are the layer missing here; with them, a party that reached the backend could be told apart. Managing and rotating keys and tokens reduces secondary harm after exposure. Lemma checks a party’s authority before it reads, outside the backend. If it is designed to send a check that the authority passed rather than the key itself, keys need not be held in plaintext.
Note: Lemma’s check works only when it is built in before the backend accepts queries and authority decisions are managed apart from the backend. It can be passed if the credentials of a party that holds authority are stolen. The table compares what each control checks; it does not show whether this incident would have been stopped. Lemma does not detect or prevent intrusions.
Three things to confirm about data backends
- Can your data backend be read just by reaching it over the network?
- Do you check the authority of the party reading the data, at the backend’s entry, before it reads?
- Do you avoid holding API keys and tokens in plaintext, and can you rotate them if they are exposed?
Facts and timeline
- Subject
- DeepSeek’s (AI / LLM service) backend infrastructure.
- Discoverer
- Wiz Research, during a security assessment of external infrastructure.
- Exposure point
- A ClickHouse instance was open to the outside with no authentication (
oauth2callback.deepseek.com:9000,dev.deepseek.com:9000). The open ports were 8123 (HTTP) and 9000, and arbitrary SQL could be run through a web interface with no authentication. - What was exposed
- Over a million log lines (the
log_streamtable), plaintext user chat history, API keys, secret access tokens, and backend operational metadata. - Data range
- Logs had accumulated from at least 2025-01-06 onward.
Glossary
ClickHouse — A database for collecting and querying large volumes of logs. Here it was open to external SQL with no authentication.
Responsible disclosure — Telling the party concerned about a weakness before making it public, so they have time to fix it.
Timeline
- The exposed database’s logs accumulate from this date onward.
- Wiz Research finds two ClickHouse instances during an assessment of external infrastructure.
- Wiz discloses responsibly to DeepSeek. DeepSeek remediates within about 30 minutes.
Proper names rest on primary sources (research labs). This case rests on a research lab’s responsible disclosure and does not assert whether third parties illicitly retrieved data. What has not been disclosed does not mean there were no controls.
After disclosure
- Discovery and fix: Following Wiz Research’s responsible disclosure, DeepSeek remediated the exposure within about 30 minutes.
- Industry point: The basic operational-security fact that a backend for sensitive data such as chat history could be exposed with no authentication, in a fast-growing AI service, became a focal point again.
- Possible secondary harm: Exposed API keys and secret tokens can be a starting point for moving to other systems and escalating privileges, so the importance of secret management and rotation was re-recognized.
- Regulatory context: It overlapped with debates over national regulation and usage restrictions around DeepSeek, and heightened interest in AI-service data protection and governance.
Sources
- Wiz Research: “Wiz Research Uncovers Exposed DeepSeek Database Leaking Sensitive Information, Including Chat History” (primary — the original account of the discovery; 2025-01) — https://www.wiz.io/blog/wiz-research-uncovers-exposed-deepseek-database-leak
- BleepingComputer: “DeepSeek exposes database with over 1 million chat records” (ports, exposed content, remediation) — https://www.bleepingcomputer.com/news/security/deepseek-exposes-database-with-over-1-million-chat-records/
- The Register: “DeepSeek database left open, exposing sensitive info” (2025-01-30; timeline) — https://www.theregister.com/2025/01/30/deepseek_database_left_open/
References: “The last layer left for cyber defense in the age of AI”