DeepSeek Left a Million Log Lines, Chats, and Secrets in a Database With No Authentication

In this issue - 4 parts +

Part 1. The Database Behind the Breakout Model
Part 2. Inside the Exposed Trust Boundary
Part 3. The Risk and the Governance Failure
Part 4. What to Validate Before Production

Part 1 of 4

The Database Behind the Breakout Model

On January 29, 2025, Wiz Research found a publicly accessible ClickHouse database belonging to DeepSeek, the company behind the DeepSeek-R1 model. The database was reachable through two DeepSeek subdomains and required no authentication. A person who reached the service did not need to steal a password, obtain an API token, or bypass a login. The missing control was the login itself.

Behind that open interface sat more than one million log lines dating back to January 6. Wiz reported plaintext user chat history, API keys, secret access tokens, backend details, directory structures, internal endpoint references, and operational metadata. The same system that helped DeepSeek observe and operate its service had become a public index of the service's users, secrets, and internal shape.

The timing made the control failure especially consequential. DeepSeek-R1 was commanding global attention and climbing app-store charts. On January 27, two days before Wiz published its finding, DeepSeek stopped new user registrations and cited "large-scale malicious attacks." Reporting does not establish that those attacks caused the database exposure or that the open database played a role in them. They are separate verified events. But they occurred in the same week, while the company's external attack surface was receiving extraordinary attention.

Wiz responsibly disclosed the exposure. DeepSeek locked the database down within about 30 minutes. That was a strong response after notification. It was not evidence that the earlier production state had been safe. The durable lesson is the gap between reaction and validation: an outside team found a basic public-exposure failure that multiple internal controls should have stopped before sensitive logs accumulated behind it.

authentication required

DeepSeek subdomains exposed it

1M+

log entries exposed

~30 min

to secure after notice

The verified record is serious enough without embellishment

There are two facts readers must keep separate. The exposure is confirmed: Wiz reached the ClickHouse web interface, enumerated tables with simple SQL, and saw the sensitive fields in the log_stream table. Unauthorized exploitation is not confirmed by the available reporting: it remains unclear whether anyone else accessed or downloaded the data before Wiz found it. An honest incident analysis states both.

That distinction does not make the exposure minor. Security controls exist to prevent a capable stranger from receiving an opportunity, not only to produce evidence after the stranger uses it. The open service removed the technical barrier between the public Internet and a production data store. Whether another party crossed that barrier is an incident-response question. Why the barrier was absent is the governance question.

Wiz also drew a careful research boundary. Its team said it did not execute intrusive queries beyond enumeration. The researchers described potential access paths supported by ClickHouse functionality, including reading local files depending on configuration, but they did not claim to have exercised them. This article keeps the same line: observed data is treated as fact; possible follow-on actions are treated as risk.

Two incidents in one week, not one proven attack chain

DeepSeek's January 27 registration halt and the January 29 database disclosure belong in the same operational picture, but not in a causal claim the sources do not support. The registration event proves the service was facing what DeepSeek called large-scale malicious attacks. The database finding proves a sensitive production service was publicly reachable without authentication.

For governance leaders, the combined signal is pressure. Launch weeks compress decision time, multiply Internet reconnaissance, and create incentives to treat security review as something that can catch up later. That is exactly when an enforced gate matters most: it does not depend on the team remembering every control while traffic, headlines, and incident queues are all rising.

Thirty-minute remediation is response, not prevention

DeepSeek deserves credit for locking down the database quickly after Wiz reached the right contact. Many disclosures stall in intake queues or ownership disputes. Fast containment reduces the exposure window after a report and is an important measure of operational readiness.

But mean time to respond begins only after detection. It says nothing about how long a condition existed before detection, which parties may have found it, which secrets require rotation, or whether the approved design ever matched the deployed state. A mature program measures both sides: how reliably unsafe states are prevented and detected internally, and how quickly the organization contains them when prevention fails.

The model was not the only AI system. The public endpoint, the ClickHouse instance, the logging pipeline, and every secret written into it were part of the system users trusted.

Coming up in Part 2 - how two non-standard ports led to a browser-queryable database, why each exposed data class changes the risk, and where the verified evidence stops.

Part 2 of 4

Inside the Exposed Trust Boundary

...

What you missed: the DeepSeek exposure was a confirmed, unauthenticated production database, while unauthorized use remains unconfirmed. It coincided with a separately reported attack wave and was contained quickly only after an external team found it.

The query path was short and ordinary

Wiz began by mapping DeepSeek's publicly accessible domains and looking beyond the standard web ports. On oauth2callback.deepseek.com and dev.deepseek.com, the researchers found ClickHouse exposed on ports 8123 and 9000. The /play path presented ClickHouse's web interface. From a browser, a simple SHOW TABLES query listed accessible data sets. The log_stream table contained the sensitive records.

None of those discovery steps required a novel exploit. Subdomain discovery, port enumeration, service identification, and a built-in query interface are normal parts of external reconnaissance. That is precisely why "security through obscurity" fails here. A non-standard port is not a control, a development-looking hostname is not a control, and a management interface that happens not to be linked from the home page is still public if the network will answer it.

The architecture collapsed three boundaries at once. The network boundary allowed the public to reach a database interface. The identity boundary did not require a user or service to authenticate. The data boundary allowed operational logging to contain material valuable far beyond troubleshooting. Each failure amplified the next.

Verified point	What happened	Control that should have supplied proof
January 6	Earliest date in the exposed logs reported by Wiz	Data classification, logging minimization, retention, and secret scanning
January 27	DeepSeek halted new registrations, citing large-scale malicious attacks	Elevated external-exposure review during a high-attention launch
January 29	Wiz reached the open ClickHouse interface and responsibly disclosed it	Continuous attack-surface discovery and unauthenticated external probing
About 30 minutes later	DeepSeek locked the database down	Named ownership, containment, evidence preservation, and secret rotation

Four data classes, four different paths to harm

"A million log lines" describes volume, not consequence. The consequence comes from what the log stream combined. Each category carries a distinct obligation, and the combination is more dangerous than any category viewed alone.

1 - Plaintext chat history

Conversation content is user data, not disposable telemetry. It may contain questions, pasted business material, personal information, code, or other context supplied in reliance on the service. Plaintext logging makes the observability system a second repository for content users thought they were sending to the application.

2 - API keys and access tokens

A secret is stored authority. The reporting does not establish that the exposed keys were used, what each key could reach, or whether they remained valid. It does establish that reusable credentials appeared in a publicly queryable log stream, creating a second control problem beyond the database itself: every affected secret had to be identified and treated as potentially disclosed.

3 - Backend and directory details

Internal paths, service names, and directory structures reduce the work required to understand an environment. They can turn a blind attacker into an informed one by showing where data moves, which components exist, and how operational systems describe themselves. Architecture knowledge has value even when it grants no direct permission.

4 - Endpoint and service metadata

References to internal APIs, source services, request origins, and chatbot metadata connect the other fragments. This context can reveal which credential belongs to which workflow or which conversation flowed through which service. Aggregation turns scattered low-level details into a map.

Exposed material	Immediate governance issue	Required response question
User chats	Sensitive content duplicated into plaintext operational logs	Whose data was present, for what purpose, and for how long?
Keys and tokens	Possession may confer authority outside the exposed database	What did each secret authorize, and has it been revoked or rotated?
Backend details	Internal topology becomes external reconnaissance material	Which exposed components now need additional review or hardening?
Operational metadata	Context links people, requests, services, and secrets	Can responders reconstruct the affected relationships without widening access?

What the evidence proves, and what it does not

Incident reporting becomes unreliable when exposure, access, exfiltration, and misuse are treated as synonyms. Here, the public query path and sensitive records were directly observed. The sources also report that DeepSeek secured the database after disclosure. They do not establish who else discovered it, whether another party ran queries, whether data was downloaded, or whether an exposed credential was used.

Those unknowns are not a reason to minimize the event; they define the response plan. Teams need preserved access logs, query history, network telemetry, secret inventories, and credential-use records to narrow the unknowns. If the exposed service did not retain evidence sufficient to answer them, that is an additional readiness gap, not proof that nothing happened.

This is also why logging policy cannot be separated from incident response. The organization needs enough evidence to investigate who reached a service, but it should not place raw chats and reusable secrets into that evidence store. Useful telemetry records decisions, identities, destinations, timing, and policy outcomes. It does not indiscriminately copy the most sensitive payload into a database whose own access controls may fail.

The AuthorityGate take

The most important word in "AI security" is not AI. It is system. DeepSeek's model did not have to jailbreak itself for this incident to matter. The infrastructure around the model created a direct path from an ordinary browser to user content and operational authority.

Governance has to evaluate the proposed production state, not the team's intention. "This is an internal database" is an intention. An external probe that receives an unauthenticated SQL interface is evidence. The decision gate should require that evidence before approval, then keep checking because DNS, ports, routes, authentication, and logging behavior can drift after release.

Coming up in Part 3 - a severity map for the confirmed exposure, the recurring organizational shortcuts behind it, and the difference between a security promise and deployable proof.

Part 3 of 4

The Risk and the Governance Failure

...

What you missed: ordinary reconnaissance reached ClickHouse on two subdomains, and its log stream combined chats, secrets, backend details, and service metadata. The exposure is proven; third-party exploitation is not.

Risk severity: assess the condition, do not invent the outcome

The table below is AuthorityGate's assessment of the control conditions described by the sources. "Critical" does not mean a downstream compromise was proven. It means the confirmed state removed a primary protection from material whose unauthorized use could carry serious consequences. Severity guides containment and investigation; evidence determines what actually happened.

Risk category	Observed evidence	Business exposure	Severity
Public database control	Browser-accessible SQL with no authentication	Anyone who discovered the service could query internal data; Wiz described full database operations and potential privilege escalation	Critical
Sensitive user content	Plaintext chat history in the log stream	Privacy, confidentiality, notification, and trust obligations may be implicated depending on affected data and jurisdiction	Critical
Reusable authority	API keys and secret access tokens present in logs	Affected secrets may create access outside the database until their scope, validity, use, and rotation are resolved	Critical
Infrastructure intelligence	Backend, directory, endpoint, source, and service details	Internal context can reduce the cost of follow-on reconnaissance and make other weaknesses easier to target	High
Detection uncertainty	External researchers discovered the condition; other access remains unclear	Response scope depends on whether retained evidence can identify earlier queries and credential use	High

Why this basic pattern keeps recurring around advanced systems

Wiz put the paradox plainly: while the industry focuses on futuristic AI threats, immediate risk often comes from the infrastructure and tools supporting AI applications. That is not an argument to ignore model-specific threats. It is an argument against using the novelty of the model to excuse ordinary control debt behind it.

Five organizational habits make this exposure pattern predictable.

1.Teams review architecture, not reachable reality. A diagram labels the database internal while a DNS record, route, container port, or load balancer makes the deployed service public. Only an external test can settle which version is true.
2.Development names are mistaken for development controls. A dev hostname communicates intent to employees. It communicates a target to an Internet scanner. Environment labels never replace authentication or network policy.
3.Logs escape normal data governance. Observability pipelines ingest whatever helps debugging, so chat payloads and credentials can be copied into stores with broader access, longer retention, and weaker review than the systems of record.
4.Launch pressure turns exceptions into production state. During rapid growth, temporary exposure and verbose logging solve immediate operational problems. Without an owner, expiry, and automated revalidation, temporary becomes the live design.
5.Fast response is allowed to stand in for prior assurance. A team that can fix an issue quickly may still lack the continuous inventory and validation that would have found it first. Recovery maturity and prevention maturity are different capabilities.

Replace security promises with production proof

"Authentication is enabled" is a configuration claim. "An anonymous request from outside the trusted network is denied on every exposed interface" is validation evidence. "We do not log secrets" is a policy statement. "Automated scanning found no credential pattern or raw chat payload in a representative stored log sample" is evidence. Mature governance turns each important promise into an observable acceptance test.

That proof must cover the live system. Infrastructure-as-code review is necessary, but the running environment also includes manual changes, DNS, inherited defaults, image behavior, proxies, firewalls, service interfaces, and drift. The approved template and the reachable endpoint are different artifacts. Both need to pass.

Finally, proof needs an owner and a validity period. A passing scan from last quarter cannot authorize a newly exposed port today. Each public endpoint, logging destination, and credential path needs a named human who receives drift alerts, can contain the service, and knows which evidence is required before reopening it.

Our take: this was an authorization failure before it was a data failure

The database state implicitly authorized the entire Internet to query a store that contained user conversations and operational secrets. Nobody intended to grant that authority, but production enforced it anyway. Governance has to judge authority by what the system permits, not by what the team meant.

The corrective control is a decision boundary between a proposed change and the authority it creates. If a deployment adds a public route, opens a management interface, removes authentication, or expands sensitive logging, the change should stop until a named expert sees the evidence, accepts the risk, and confirms the recovery plan. The same boundary keeps validating after deployment so drift cannot silently create a new grant.

Coming up in Part 4 - the concrete validations to implement, a self-assessment checklist, and a gate-by-gate map from the DeepSeek failure to accountable production controls.

Part 4 of 4

What to Validate Before Production

...

What you missed: the confirmed condition was critical even without proof of exploitation. Architecture-review gaps, development-host assumptions, ungoverned logging, launch exceptions, and external-first detection explain why an elementary control failure survived behind a high-profile AI service.

Eight practical steps

The response is not a generic reminder to "secure the cloud." It is a set of specific tests, owners, and recovery actions that make this class of exposure harder to create, faster to detect, and safer to contain.

Inventory the whole AI data plane

List every public and private subdomain, IP address, port, load balancer, proxy, database, log collector, object store, queue, and management interface that supports the AI service. Give each asset a named owner, approved exposure level, data classification, and review date. An inventory that includes only the model endpoint will miss the system that stores its prompts and secrets.

Prove anonymous access is denied from the outside

Test the live endpoint from a network that has no trusted identity or private route. Check every protocol and management interface, including non-standard ports, and verify the response is a denial rather than a usable query surface. Repeat after DNS, proxy, firewall, and deployment changes.

Make authentication an invariant, not an option

Enforce authenticated, authorized identities at the database and network layers. Remove default or anonymous users, scope service accounts to the minimum operations and data they need, and prefer short-lived credentials. A hidden hostname and an unadvertised port do not count as identity controls.

Minimize and scan stored logs

Define which fields are necessary for reliability and security, then redact or exclude raw chat content, API keys, access tokens, authorization headers, and other secrets before storage. Scan both the logging configuration and the records that actually land. The deployed output is the evidence.

Continuously compare approved and reachable state

Watch certificate transparency, DNS, cloud inventory, firewall rules, load balancers, and Internet-facing services for new exposure. Compare the observed state with the approved design and block or contain unexplained drift. The check should become more sensitive, not less, during launches and attack activity.

Separate detection evidence from sensitive payloads

Retain enough tamper-evident metadata to reconstruct who connected, what query or action was attempted, which identity and service were involved, and what policy decision occurred. Avoid solving forensics by copying full sensitive payloads into a second weakly governed store.

Pre-stage containment and secret rotation

Document how to isolate the endpoint without destroying evidence, enumerate the secrets present in affected logs, revoke or rotate them, and search their authorized systems for suspicious use. Database lockdown is the first containment step, not the end of impact assessment.

Exercise the decision path with named humans

Route public data-store exposure, authentication changes, and sensitive logging changes to accountable platform, security, and data owners. Drill the reject, rollback, and incident-escalation path so launch pressure cannot turn an approval gate into an informal message thread.

Governance checklist

Can your organization prove each statement for the real production service today?

Every AI-supporting subdomain, port, database, logging endpoint, and management interface appears in a current inventory with a named owner.

An independent external test confirms that anonymous users cannot query any production database interface.

Authentication and network policy are enforced on ports and protocols beyond ordinary web traffic.

Stored logs are sampled and scanned for raw chat content, API keys, access tokens, and authorization material.

Logging minimization and retention rules are based on the sensitivity of the data, not only on storage cost.

A drift monitor alerts the owner when DNS, routes, firewall rules, or public services diverge from the approved state.

Public exposure, authentication removal, and sensitive logging changes require a named security and data-owner approval that cannot be skipped.

Access and query evidence can establish who reached the service without relying on sensitive payload copies.

Responders can enumerate and rotate every credential that may have entered an exposed log stream.

Endpoint isolation, evidence preservation, user-impact assessment, and rollback have been rehearsed together.

AuthorityGate 8-gate governance mapping

This incident spans every gate because the unsafe state crossed change approval, identity, data handling, dependency, runtime behavior, ownership, and recovery. No single scan is sufficient; the value comes from independent proofs that fail closed.

Pre-Validation

Record the approved network exposure, authentication mode, data classification, logging policy, owner, and known-good configuration before the database change begins.

ITSM Window Check

Bind database, DNS, load-balancer, and logging changes to an approved window with staffed owners and an expiry instead of letting launch pressure create an exception.

Zero Trust Verification

Require an authenticated and authorized identity at every ClickHouse interface; deny public anonymous queries and remove ambient or long-lived service authority.

Security Scan

Scan infrastructure code and the live endpoint for open ports, missing authentication, exposed management paths, and secrets or chat content entering stored logs.

Dependency Validation

Map the subdomains, DNS records, proxies, collectors, database nodes, applications, and downstream credentials so the full trust boundary is reviewed as one system.

Operational Resilience

Deploy the proposed state in a production-mirroring environment, probe it from outside the trusted network, and continuously compare the live state for exposure drift.

SME Approval

Require named security, platform, and data owners to approve any public data-store interface or expansion in sensitive logging before it reaches production.

Recovery Plan

Pre-stage endpoint isolation, evidence preservation, secret rotation, user-impact assessment, and rollback to a verified configuration before sensitive data begins to accumulate.

This is what the validation layer is for

AuthorityGate Keystone places a configurable decision boundary between a proposed infrastructure change and the production authority that change would create. A routine private database update can clear automatically when its evidence matches policy. A change that opens a public route, exposes a management port, removes authentication, or begins logging sensitive content stops for the appropriate experts.

The result is not a promise that misconfiguration can never happen. It is a system of independent checks, named ownership, decision receipts, drift detection, and tested recovery. If one layer fails, the next has enough evidence and authority to prevent an unintended production state from becoming a silent, long-lived grant to the Internet.

The bottom line

DeepSeek secured the database quickly after Wiz raised the alarm. The verified failure remains stark: during the week R1 made the company one of the most watched AI providers in the world, a production ClickHouse database was publicly queryable with no authentication. More than one million log entries exposed plaintext chats, API keys, access tokens, backend details, and operational metadata dating back to January 6.

The available sources do not prove that another party accessed or misused the data, and they do not connect the database to the separately reported malicious attacks. Good governance does not need those unsupported claims. The confirmed state already shows a complete breakdown in network exposure, identity enforcement, sensitive logging, and internal detection.

AI systems inherit the security of every endpoint, database, token, log collector, and deployment decision behind the model. A model can pass its evaluations while its surrounding system fails an elementary production test. That is why model governance alone is incomplete: the organization must validate the authority created by the whole deployed stack.

The winning control is simple to state and demanding to operationalize: before production, prove that the real endpoint enforces the approved boundary; after production, keep proving it. Give every exception an owner and expiry, every consequential change an accountable approval, and every failure a tested path back to a known-good state.

Sources

Share this analysis

Share on LinkedIn Share on X