This documents a serious infrastructure failure in 2025, with an unknown affected-user count. It establishes neither present exposure nor present safety, and says nothing about AIHackers’ October 2026 requests. A cheap, capable model and a provider that protects customer data are separate evaluations. Keep both in your buying decision.
Wiz’s January 30, 2026 retrospective ranks its original DeepSeek investigation first among its most-read research posts of 2025. It reviews that investigation; it does not announce another exposure. This article’s October 8 source review covers the historical reports, not today’s infrastructure or account controls.
Confirmed findings and unresolved questions
Wiz’s original disclosure, under Executive Summary and Exposure Walkthrough, describes unauthenticated ClickHouse access, SQL execution through its web interface and demonstrated table enumeration.
| Confirmed or reported | What remains unknown |
|---|---|
| Wiz observed chat text, API keys and operational data in logs. | Which people were affected; whether every service’s data was included. |
| The retrospective recalls over one million log entries. | A user total: records are not people. |
| Wiz reports full database control and potential privilege escalation. | The extent of additional access actually exercised. |
| Wiz described prompt remediation. | Outside-access history, theft, misuse or a comprehensive audit. |
The original walkthrough’s password and local-file examples describe conditional capabilities, dependent on configuration. Wiz says it did not execute intrusive queries beyond enumeration. Those examples do not establish stolen passwords or retrieved files.
Treat this as a documented access-control failure. The public sources do not supply a complete incident accounting, so neither a numerical victim estimate nor a clean bill of health follows.
Short timeline and coverage context
- January 6, 2025: date of logs noted by Wiz; not an exposure-start date.
- January 29, 2025: Wiz published its disclosure. Reuters’ syndicated report attributes closure in under an hour after notification to Wiz CTO Ami Luttwak.
- January 30, 2025: The Verge covered the finding and unresolved outside access.
- January 30, 2026: Wiz revisited the investigation in its annual retrospective.
Reuters and The Verge principally report Wiz’s investigation. Their coverage adds reporting and attribution, not two independent technical audits. Reuters also relays Luttwak’s concern that others could have discovered the database; a concern is not evidence that they accessed it. Closing the reported access path cannot reconstruct who previously used it or what copies remain.
Four evaluations to keep separate
These are decision questions, not a current provider rating.
1. Model capability and accepted-result cost
Evaluate the exact model, task and serving route. A benchmark score or low token price can help select a candidate, but your relevant measure is a correct result after checking and repair. Offensive-task capability asks whether a model can find or exploit weaknesses in a target application. It does not evaluate customer-data protection at the company serving it. Historical results belong to their original model versions and test conditions.
2. Provider infrastructure security
Ask who operates the service and what evidence supports its access controls, logging practices and incident response. Give a historical infrastructure failure appropriate weight without turning its remediation into a present security certification. For sensitive work, identify an accountable operator and request evidence relevant to your deployment. A model’s weights do not describe the configuration of the database, gateway or monitoring service around them. Missing evidence should remain an open question.
3. Data-handling terms
Check the terms for the actual product and account: consumer chat, direct API, intermediary or managed business service. Ask about retention, training use, deletion, exceptions and recipients. Contractual permission and technical enforcement require separate checks. An opt-out label alone does not answer every retention question. Start with the data-retention comparison as a framework, then inspect the provider and route you intend to use.
4. User sharing controls
Review what you deliberately send, upload or publish, including outputs derived from private inputs. For public links, ask who can open the snapshot, forward it and revoke access. For connected tools, ask which additional services receive data. Use fictional or redacted material for an initial trial. Sharing choices and provider infrastructure have different owners; neither evaluation substitutes for the other. Keep a practical way to stop sharing or disconnect an integration.
Claude’s searchable public snapshots illustrate another mechanism: user-created sharing, without established unauthorized access to unshared chats.
Deployment reasoning: who receives the data?
This comparison is architectural reasoning, not a claim about any provider’s present controls.
| Deployment | Questions to resolve |
|---|---|
| DeepSeek-hosted service | What does DeepSeek receive, retain and log for this product? Who owns its infrastructure controls? |
| Another provider serving DeepSeek weights | Which host or intermediaries receive requests? What are their terms and operational responsibilities? |
| Self-hosting | Does inference stay local? Who maintains serving software, access, logs, backups and connected services? |
Changing the operator changes the data path and responsibility. Self-hosting can remove a remote inference recipient when configured that way, while leaving your own security work and any external integrations to inspect. Open weights do not make administration effortless or certify a deployment.
Before sending sensitive material, write down the input, recipients and responsible operator. Evaluate a bounded task with nonsensitive data, then make the separate data-handling decision. The local-model guide develops that deployment option; Risks & policy provides other incident and policy contexts.