What Fowler found
Jeremiah Fowler, a security researcher who has made a habit of finding unsecured databases, located a database holding 13.7 million records with no encryption and no password protection. He traced the server's IP address to a data intelligence platform operated or developed by Vibetech, a software company based in India. Nothing about the database required credentials to access it. Anyone who found the IP address could browse the contents directly, the same exposure pattern Fowler has documented at dozens of other companies over the past several years.
The archive was organized by source company rather than by individual, which made its origin easy to trace once found. Close to 8 million records came from an earlier AT&T breach. Another 1.2 million were tied to Amazon, 420,000 to Walmart, 24,000 to BluBank Digital Bank, 18,000 to PayPal, 4,084 to the FBI Employee Directory, and 929 to Interpol. Fowler described finding accounts and credentials belonging to individuals across multiple countries even in a limited sample review.
The business model behind the exposure
What makes this case worth a CTO's attention is not the misconfiguration itself, which is ordinary, but what the database was for. Vibetech's platform appears built around aggregating data, including data that originated in other companies' breaches, into a searchable intelligence product. That is a different risk profile than a company accidentally exposing its own customer records. It means the exposed data was never Vibetech's to begin with, and the breached parties, AT&T's customers, Amazon's customers, Walmart's customers, had no relationship with Vibetech at all.
Data aggregation and enrichment vendors occupy an unusual position in the vendor landscape. They are frequently used by sales, marketing, and risk teams specifically because they hold data a company would otherwise have no legitimate way to access on its own. That business model depends on collecting sensitive records from many sources, and this incident shows what happens when the security investment protecting that collection does not match the sensitivity of what has been gathered into one place.
Why aggregation makes breach data more dangerous
A single breach at AT&T or Amazon is bad on its own, but it typically yields one category of data from one company's systems. An aggregator that pulls together login credentials, phone numbers, bank details, and government employee records from a dozen different breaches creates something more dangerous than any individual incident: a cross-referenced profile that lets an attacker match a password from one leak to a phone number from another and a bank account from a third, all for the same person.
That cross-referencing is precisely the value proposition data intelligence platforms sell to legitimate customers, and it is exactly what makes a security failure at one of these platforms more consequential than a similar failure at a company exposing only its own first-party data. The entries from the FBI Employee Directory and Interpol sitting in the same unprotected archive as consumer banking credentials illustrate how aggregation collapses distinctions between data types that organizations normally keep separated for good reason.
The basics that were still missing
Encryption at rest and a password requirement are not advanced security controls. They are baseline expectations for any database holding personal data, let alone a database built specifically to hold sensitive records sourced from other companies' breaches. Their absence here is consistent with a now-familiar pattern in these disclosures: the technical sophistication required to build a data aggregation and matching product rarely correlates with the operational discipline required to secure the resulting database.
This gap recurs often enough across similar incidents that it is worth treating as a baseline assumption rather than an exception when evaluating any vendor whose core function involves storing data at scale. A sales pitch built around a platform's analytical capabilities says nothing about whether that platform's underlying storage is encrypted, access-controlled, or monitored, and those questions deserve direct answers before a contract is signed, not after a researcher finds the gap first.
What this means for vendor risk programs
Most third-party risk questionnaires focus on a vendor's handling of the data a company directly hands over to it. This incident argues for a broader question: what other data has this vendor aggregated from elsewhere, and under what security posture is that aggregated data held? A data intelligence or enrichment vendor's risk profile should be evaluated based on everything in its database, not only the slice relevant to the buyer's own contract.
That is a harder question to get a straight answer to, since vendors in this category are often reluctant to detail exactly what data they hold or where it originated. A reasonable minimum is to require evidence of encryption at rest, documented access controls, and a named security contact as a condition of any contract with a data aggregation or enrichment vendor, rather than accepting a general security attestation that does not address the specific risk this category of vendor presents.
The decision data and security leaders face
If your organization uses a data enrichment, intelligence, or lead-generation vendor whose core product depends on aggregating records from many sources, that vendor belongs in a distinct risk tier from a typical SaaS tool, with security requirements to match. The usual vendor questionnaire, built around how a company protects data a customer directly provides, does not capture the risk a vendor like Vibetech represents, because the exposure that matters most sits in data the vendor sourced from somewhere else entirely.
Build a specific review track for this vendor category now, before a procurement cycle forces the question under time pressure. Ask what data the vendor has aggregated, from where, and under what security controls, and request evidence rather than assurance. The alternative is finding out the answer the way Fowler's reporting keeps finding it, after the database is already exposed to anyone who happens to look, by which point the only remaining decision is how to explain it to the customers whose data ended up there without their knowledge.
