For those who, contrary to Cursors DeepSeek properly setup availability through Fireworks servers, want to use the original DeepSeek servers: Your data was exposed. Congrats!
A severe security incident was discovered involving DeepSeek’s internal services. The company had an exposed ClickHouse database that contained sensitive information, including customer request history and observability data (OpenTelemetry spans).
Technical Details
The exposure was particularly concerning because the database was accessible:
- Without any authentication
- Contained logs with request data of customers - Included development infrastructure and observability data
Security Implications
This incident raises serious questions about DeepSeek’s security practices, especially considering that:
- ClickHouse’s default installation process explicitly requests setting up a password
- The default configuration restricts external network access and limits the default user to localhost only
- Multiple authentication methods were available but not implemented, including:
- Password authentication with bcrypt/sha256
- Certificate authentication
- SSH key authentication
The exposure was particularly notable as it allowed complete database control and potential privilege escalation within the DeepSeek environment without any authentication measures in place
Additional
[3] Italy’s privacy regulator goes after DeepSeek | Hacker News Italy's privacy regulator goes after DeepSeek | Hacker News
[4] Exposed DeepSeek database leaking sensitive information, including chat history Exposed DeepSeek database leaking sensitive information, including chat history | Hacker News
Just to clarify. This is not about Cursors DeepSeek integration as they use secure Fireworks servers. The issue occurred on DeepSeek’s own servers when users used their own API access.