How This Single Bug in DeepSeek Leaked 1M+ Chat Records!

Last week, a simple bug in DeepSeek led to exposure of over 1 million chat records! An attacker could have easily exploited this to gain full database control and escalate privileges. How?

Could have—because this flaw was caught by Wiz Research before any known exploitation. Here’s how the researcher (acting as an “attacker” in this case) uncovered it:

Attack Flow:

1. Attacker starts by mapping DeepSeek’s public domains > discovers 30 internet facing sub domains > finds expected stuff (chatbot interface, APIs, etc.).
   

2. Attacker now starts scanning for non-standard open ports on these domains > Bingo! Detects 2 unusual open ports (8123 & 9000)
   
   (The two hosts are: hxxp[://]oauth2callback[.]deepseek[.]com[:]8123 and hxxp[://]dev[.]deepseek[.]com[:]8123)
   

3. Attacker investigates further > Identifies that these ports led to publicly exposed database accessible without any authentication! > The database is ClickHouse database used for real time data processing.
   

4. Attacker simply appends "/path" to the URL (this is the standard path that allows direct execution of SQL queries via browser with ClickHouse) > This returns a full list of accessible datasets > Among them, one table "log_stream" contained over 1 million log entries > Which contained Chat history, API keys etc.

Key Insights:

1. If you think about it, a simple misconfiguration on a single cloud asset could lead to a massive breach of your entire company's data! All an attacker needs to do is find that one simple mistake. That’s the asymmetry in cybersecurity.
   

2. Cloud misconfigurations are everywhere. Almost every company fell for this class of vulnerability one time or the other. Why?

   1. A developer assumes cloud services have secure configuration by default (but that is not always the case). Several services require manual configuration post creation to restrict access.

   2. A developer enables broad access during testing process as a quick workaround but forgets to remove it. The same config goes into production.

   3. A developer creates cloud resources without proper IT and Security team's oversight (aka Shadow IT problem)

   So, yes, this problem is dependent on solving many other systemic issues such as security hygiene, default access control policies, gating testing to production changes and so on.
   

3. But consider this for a second: It is your endpoint. It is you who enabled the unauthenticated access. But someone else found out about it before you did. How? Because they were ready for it.
   

4. If an attacker can continuously scan your IPs, sub domains and identify accidentally exposed databases, you should be able to do that too. In fact, with the level of control and visibility you have on your assets, you should be able to do that before they do.
   

5. Build the security capability to automatically identify your company's public assets, scan them for ‘anonymous access’ and respond rapidly for the identified cases. Beat attackers at their own game.