October 11, 2026
Recreating the DeepSeek Database Leak Wiz Research Found
Back in January 2025, Wiz Research found a completely open, unauthenticated ClickHouse database sitting on the public internet, tied…

By L4ZZ3RJ0D
5 min read
Back in January 2025, Wiz Research found a completely open, unauthenticated ClickHouse database sitting on the public internet, tied straight to DeepSeek. No login, no API key, nothing, just a browser tab away from chat logs, internal API keys, and plaintext secrets belonging to one of the biggest AI companies on the planet at that exact moment. Wiz's own writeup covers exactly how they found it, and it's worth reading straight from them if you haven't already.
What I actually worked through here isn't the real DeepSeek environment, obviously, it's a recreated version of that exact scenario built by Bug Bounty Masterclass, modeled closely enough on the real incident that the methodology carries over directly. The target root domain throws a handful of decoy subdomains at you alongside the one that actually matters, so the real lesson here isn't really "find an exposed database," it's "don't waste your whole session chasing shiny decoys before you've even confirmed what's live."
Started with passive subdomain enumeration against the root domain.
Twenty subdomains came back, airlines, casino, fintech, bank, a GitHub enterprise instance, something called vibecoded, and buried in there, deepleak, which on a target modeled after a database leak is about as unsubtle a hint as /mail was in a completely different room. Still, a subdomain list from a passive source doesn't tell you what's actually alive right now, so before chasing any of them specifically, they all needed resolving and probing properly.
Ran the resolved list through httpx to check status codes, titles, and redirect targets across the board rather than guessing which ones mattered.
Most of them came back as exactly what you'd expect from a fake airline site or a casino decoy, nothing worth chasing. But deepleak redirected straight out to a real tweet referencing the original Wiz disclosure, which confirmed the naming wasn't an accident, this was the actual target wrapped in a pile of noise. That's one subdomain confirmed, but a single HTTP response on port 443 rarely tells the whole story, so the next question was what else that same host might be exposing on other ports entirely.
Ran a full port sweep against just that one host instead of the whole subdomain list, and it came back busy, 443, 80, a handful of unusual high ports, and a couple that immediately stood out next to each other, 8080 and 9000. Needed to actually see what was living behind each of those before assuming anything. Fed that full port list back through httpx to get titles and status codes across every one of them at once rather than checking each manually.
A few came back as ClickHouse directly, worth remembering for later, and one labeled itself a cluster management portal.
Port 8080 turned out to be exactly that, a cluster management portal redirecting to SSO, and poking at the raw request traffic sitting behind it in Caido turned up a JavaScript bundle leaking what looked like hardcoded AKS credentials, a resource group name, a cluster name, and a bearer token, all sitting inside a bundled JS file that should never have shipped with that information baked in. Real finding, genuinely embarrassing misconfiguration, but not actually the flag this particular exercise was built around, so it went on the list and I kept moving.
A second staging environment nearby, a router resellers portal, handed over a full dashboard, inventory, pricing, order history, to a guest account with zero authentication required at all. Another real misconfiguration, another one that wasn't the actual target. Worth noting both of these on their own would be solid findings on a real engagement, but the room clearly had one specific thing it wanted found, so the ClickHouse instance on port 9000 was still the lead worth chasing properly.
Hit it directly, and it answered instantly, a live ClickHouse web interface sitting wide open, no credentials asked for at any point.
Ran a basic SHOW DATABASES just to see what was actually sitting on the instance before doing anything more targeted, and deepleak was right there in the list alongside the default system schemas, about as clear a signpost as this challenge was ever going to give.
Pulled everything out of its log_stream table, and this is the exact shape of what made the real DeepSeek incident so bad in the first place, over a thousand rows of structured application logs sitting there completely unauthenticated, login events with real-looking user IDs and emails, API keys tied to specific accounts, full database connection strings with embedded passwords, JWT tokens, even a logged chat exchange where a user straight up asked for admin credentials and got a usable answer back. Every string in that table here is obviously synthetic, built specifically for this exercise rather than pulled from anyone's real environment, but that's precisely what makes it worth sitting with for a second, this is genuinely what unauthenticated log access looks like at the byte level. It's not an abstract severity rating on a report, it's literally every secret a backend ever touched, sitting there in plaintext, available to anyone who happened to find the right port.
Flag included in that same dump, confirming the chain start to finish actually led somewhere real.
Three separate issues came out of one single target in the end, not just the one the room was built around. A JavaScript bundle shipping hardcoded cloud credentials it should never have shipped with. A staging environment that handed out full functionality to an unauthenticated guest account. And underneath both of those, the actual headline finding, a production-grade logging database with zero authentication standing between it and the open internet. None of these are exotic techniques, nothing here involved writing custom exploit code or chaining five separate bugs together, it was straightforward enumeration, actually reading what came back at every step instead of only chasing the one path that looked most interesting, and checking ports most scans skip past without a second look. Which is exactly the point, and exactly why the real version of this cost DeepSeek the way it did, the hard part was never some advanced technique, it was that nobody checked whether port 9000 was supposed to be open to the world in the first place.
Happy hunting, see you in the next scope :)