DeepSeek's Exposed Database and the Cost of a Missing Password

In late January 2025, the Chinese AI lab DeepSeek was having the best week of its short life; its models had gone viral and downloads were surging. In the middle of that spotlight, Wiz Research found something considerably less flattering: a DeepSeek database sitting on the public internet with no authentication in front of it.

The exposed system was a ClickHouse database — a high-performance store often used for logs and analytics — reachable on DeepSeek-owned hosts. Wiz reported that it required no credentials at all: an outsider could connect and issue arbitrary queries with full control over the contents. This is not an exotic zero-day. It is the oldest cloud mistake there is, applied to a brand-new AI company.

What was in it

According to Wiz, the database held more than a million log lines, including plaintext chat history, API keys and other secret keys, backend and operational metadata, and internal service details. An attacker with the access Wiz demonstrated could have run queries to pull those logs and plaintext conversations, and potentially reached further into the environment.

Report it precisely

The careful phrasing matters here, and Wiz was careful. They discovered the exposure, disclosed it responsibly, and DeepSeek locked the database down promptly. Wiz could not determine whether any malicious third party accessed the data before it was secured. So the accurate statement is that highly sensitive data was exposed and could have been accessed — not that user data was confirmed stolen by attackers. That distinction is the difference between fair reporting and sensationalism.

It does not soften the lesson. The window during which a database like this is open is exactly the window internet-wide scanners are built to catch, and a viral product is precisely when opportunistic scanning intensifies. Speed of growth had outrun the security basics — a pattern common to fast-moving AI startups, and one their enterprise customers inherit.

Two things make this more than a routine misconfiguration story. The first is the port: a ClickHouse instance answering on its native port with no authentication is discoverable by the same internet-wide scanning that indexes every other exposed service, so there is no obscurity to hide behind and the interval between exposure and discovery is measured in hours. The second is what an AI product's logs actually contain. Ordinary application logs are dull; the logs of a chatbot are a transcript of what users typed, which for many includes code, credentials, and confidential business context they would never put in an email. That is why plaintext chat history in an analytics store is so much worse than the same volume of generic log lines — the sensitivity is concentrated.

What defenders should take away

• Never expose a datastore without authentication. Databases belong on private networks, bound to internal interfaces, behind credentials and network controls — verified, not assumed.
• Do not log secrets in plaintext. Chat content and API keys sitting in analytics logs turn a single exposure into a full-blown secret leak; redact and encrypt what you store.
• Scan your own perimeter continuously. Find the open port before a researcher — or an attacker — does, and alert on any datastore that becomes internet-reachable.
• Vet your AI vendors' hygiene. If you send data to an AI provider, their basic cloud posture is now part of your risk surface.

DeepSeek's exposure is a reminder that the AI in a company's name changes nothing about the fundamentals: an internet-facing database with no password is an incident waiting to be indexed. The first defence is knowing every datastore you have stood up and where it is reachable from — because you cannot defend what you have not discovered.