No More Privacy: 202 Million Private Resumes Exposed in an Unsecured Database

What Happened: An 854GB Database of Resumes Left Wide Open

On December 27th, 2018, an unprotected MongoDB instance appeared in Shodan's index of internet-facing databases. The following day, security researcher Bob Diachenko identified it and confirmed what it contained: 202,730,434 detailed resume records, totaling 854GB, sitting on a server with no password, no authentication, and no barrier between the data and anyone who found it.

This wasn't a list of names and emails. Each record was a genuinely detailed personal profile—the kind of information a job seeker would only hand over to a platform they trusted with their career.

What Data Was Exposed

Each of the 202,730,434 records included:

• Mobile phone number and email address
• Marital status and number of children
• Political affiliation
• Height and weight
• Driver's license status
• Literacy level
• Salary expectations
• Full resume and employment history details

That combination—contact details alongside marital status, political affiliation, and physical characteristics—goes well beyond what any legitimate hiring process needs, and well beyond what most of the people in this database likely knew they'd shared with anyone beyond the site they applied through.

Where Did the Data Actually Come From?

No company ever stepped forward to claim this database. The strongest lead came from a GitHub repository for a web scraping tool called "data-import," created roughly three years before the database was found, which pointed toward Chinese classifieds and job-listing sites—including bj.58.com, one of China's largest classifieds platforms—as likely sources.

The repository's own source code made the intent hard to argue with. Its ResumeInfo class defined fields—with Chinese-language comments—for exactly the data categories later found in the exposed database: name, gender, birthday, mobile phone, email, and, notably, "politics_stat" (political status) and "hukou" (household registration).

The repository's file structure—organized into folders for caching, data access, service logic, and utilities—read less like a hobby script and more like a production-grade data pipeline built specifically around 58.com's site structure.

When approached, 58.com's security team denied responsibility directly: "the sample data is not leaked from us... the data is leaked from a third party who scrape data from many CV websites." That statement is plausible on its face—the tooling suggests aggregation from multiple sites rather than a single company's breach—but it also means no one was ever held accountable for how 202 million people's sensitive personal data ended up sitting unprotected on the open internet. The database was secured after notification, but MongoDB's own access logs showed at least a dozen distinct IP addresses had connected to the instance before that happened—meaning some unknown number of parties had the opportunity to copy the data before it was locked down.

This Wasn't an Isolated Incident

This case sat inside a much larger pattern. In the first three months of 2019 alone, Chinese companies were found to have cumulatively leaked over 590 million resumes through open, unsecured databases—this 202-million-record exposure was one entry in that wave, not a standalone event. A few months later, in May 2019, the same researcher, Bob Diachenko, identified a similarly unsecured MongoDB database exposing 275,265,298 records belonging to Indian professionals. The pattern was the same each time: data scraped or aggregated at scale, then stored with no authentication whatsoever.

Is This Still Happening? MongoDB Exposure in 2026

Unmistakably, yes—and the same researcher who found this database is still finding them, at a far larger scale. In November 2025, Bob Diachenko and Cybernews identified another unsecured, no-authentication MongoDB instance—this one holding 16TB and roughly 4.3 billion scraped professional records, including names, emails, phone numbers, job titles, employers, education history, and 732 million photos, structured like LinkedIn profile data. It was discovered on November 23, 2025, and secured two days later. Seven years on, it's the same database engine, the same misconfiguration, the same scrape-then-store-insecurely pattern—just over twenty times the record count.

There's also a newer angle worth knowing about if you run MongoDB today: in December 2025, researchers disclosed "MongoBleed" (CVE-2025-14847), an unauthenticated memory-disclosure vulnerability in MongoDB Server affecting versions 4.4 through 8.2, which can leak credentials, API keys, and other sensitive memory contents to an attacker before any authentication takes place. Security scanning identified roughly 146,000 internet-exposed MongoDB instances. A working exploit became public within days of disclosure, and the vulnerability was confirmed under active exploitation shortly after. Unlike the 2018 case, this isn't a matter of someone forgetting to set a password—it's a reminder that even a properly configured, authenticated instance can still be at risk if it isn't patched.

Resume and CV data specifically has also kept turning up in breaches since. In February 2024, a group dubbed "ResumeLooters" used SQL injection and cross-site scripting to hit 65 job and retail sites across the Asia-Pacific region, stealing roughly 2.19 million records—including over 510,000 from job platforms specifically—and selling them via Telegram. In 2024, a Singapore-based hiring platform, Snaphunt, left an AWS storage bucket open, exposing more than 280,000 resume files with names, phone numbers, dates of birth, and full employment and education histories.

What This Would Mean Under China's PIPL Today

At the time of this breach, China had no dedicated data protection law with teeth. That changed with the Personal Information Protection Law (PIPL), passed in August 2021 and in effect since November 1, 2021—China's rough equivalent to GDPR, and in some respects stricter.

A comparable exposure today would very plausibly trigger PIPL obligations on multiple fronts. The law requires organizations processing personal information to implement adequate security safeguards and to notify both the regulator (the Cyberspace Administration of China) and affected individuals in the event of a leak. Several of the data categories exposed here—political affiliation, and arguably marital status and driver's license information—would likely qualify as "sensitive personal information" under PIPL, a category that requires separate consent and a stricter necessity assessment before it can be collected or processed at all. The scraping itself is a separate exposure: unauthorized data scraping increasingly draws scrutiny under China's Data Security Law and Cybersecurity Law in addition to PIPL, meaning both the party that built this database and the sites it may have scraped from could face liability today.

The scale of possible penalties has grown accordingly. Standard PIPL violations carry fines up to ¥1 million for an organization; "grave" violations can reach ¥50 million or 5% of the violating company's prior-year revenue, alongside business suspension and personal liability for responsible executives. The clearest sign of how seriously this is now enforced: in 2022, ride-hailing giant Didi Global was fined roughly ¥8.03 billion (about $1.2 billion) under PIPL and related laws for excessive and improperly secured data collection—by far the largest privacy penalty in Chinese regulatory history, and a very different outcome than "no data owner was ever identified.”

How to Secure MongoDB Deployments

The failure mode here—MongoDB with no authentication, reachable from the open internet—has a well-documented fix, and it hasn't changed much since 2018:

• Enable authentication and access control before a MongoDB instance ever goes live; never rely on network obscurity as your only line of defense.
• Bind MongoDB to a private network interface rather than a public IP address, and restrict access with a firewall or security group allow-list.
• Enforce TLS encryption for data in transit and encryption at rest for data on disk.
• Keep MongoDB patched and up to date—the 2025 MongoBleed vulnerability is a reminder that authentication alone doesn't protect against every flaw in the underlying software.
• Regularly scan your own infrastructure with the same tools attackers and researchers use—Shodan, Censys, Binaryedge—to catch an exposed or vulnerable instance before someone else does.
• If your business depends on data scraped or aggregated from third parties, treat that data with the same security rigor as data you collected directly—"we didn't collect it ourselves" is not a defense once it leaks from your infrastructure.

202 Million Resumes Exposed: FAQ