DeepSeek left a database open to the internet — chat history and API keys included

What happened

In January 2025, Wiz Research reported that the AI company DeepSeek had a ClickHouse database exposed to the public internet with no authentication. The instance was reachable at a DeepSeek-owned host, and its HTTP interface exposed an open /play console that let anyone run arbitrary SQL queries.

The exposed data was not trivial. Wiz described over a million log lines including plaintext chat history, API keys, backend details, and operational metadata — and noted that the level of access was enough to take full control of the database. For a company whose most sensitive asset is its users' conversations, a screen-door database is close to a worst case.

Root cause

This is not, at its core, an "AI" vulnerability. It is the oldest misconfiguration in the book — a datastore bound to the network with no isolation and no authentication — applied to uniquely sensitive data. OWASP promoted Security Misconfiguration to the number-two web risk in its 2025 Top 10 precisely because incidents like this keep happening. Two controls were absent: a network boundary that keeps a data service off the public internet, and mandatory authentication on the service itself.

How it would have been caught

An external attack-surface scan — a Nuclei template set, a Shodan-style sweep, or a cloud security posture tool — would have flagged an internet-reachable database port and an unauthenticated admin console immediately. The reproduction is a one-line test: from an off-network host, attempt to connect to every datastore and assert the connection is refused or challenged for credentials.

How to prevent it

• Put every datastore behind a private network and require authentication; never bind a sensitive service to 0.0.0.0.
• Encrypt sensitive data at rest, and never store chat logs or API keys in plaintext.
• Rotate any credential that could have been exposed, and run continuous external-exposure monitoring as a standing runtime gate.

The Breachwire test (red → green)

From outside the network, probe every datastore and confirm the exploit succeeds (an unauthenticated connection returns data) — proof the exposure is real. Apply the network boundary and auth, then confirm the same probe now returns connection refused / authentication required, while the application's own authenticated access still works.