Inside American Express India's Cloud Storage Exposure

What Happened: An Unprotected MongoDB Found Through Routine Scanning

On October 23rd, 2018, researcher Bob Diachenko identified an unprotected MongoDB database that anyone could view, edit, or access—no special tools required, just the IoT search engines Shodan and BinaryEdge.io. The records inside appeared to belong to an American Express branch operating in India. BinaryEdge had first indexed the database on October 20th, meaning it sat exposed for roughly five days before it was found and reported. Security Affairs independently corroborated the record counts Diachenko disclosed shortly after the find.

The scan showed a MongoDB 3.2.3 instance on the default port 27017, holding roughly 19 GB of data in a database named simply "amex." MongoDB ships with authentication turned off, and releases before 3.6 could listen on all network interfaces depending on how they were installed—so an instance like this one was open to anyone unless someone deliberately locked it down.

The same kind of open-door scanning caught a very similar exposure at a US nonprofit, when a MongoDB left wide open exposed 21,612 donor and customer records belonging to the charity Kars4Kids—a reminder that the "no authentication required" misconfiguration isn't industry-specific.

What Data Was Exposed

The database held two distinct sets of records. The first, unencrypted, contained 689,272 records with customers' phone numbers, names, email addresses, and card-type descriptions. The second, encrypted, held a much larger and more sensitive set: 2,332,115 records including names, addresses, Aadhaar numbers (India's national biometric identity number), PAN card numbers (India's tax identification number), and phone numbers.

The database also contained links to files hosted directly on the American Express India website—and those linked files held unencrypted details, including names, mobile numbers, and PAN numbers, for hundreds of thousands of additional customers. Encrypting one collection doesn't do much good when a linked file sitting one click away holds the same category of data in plaintext.

National identity numbers are what make exposures like this one so damaging, because unlike a password or a card number, they can't simply be reissued. Within weeks of this find, Diachenko uncovered the same problem in Brazil, where an unauthenticated Elasticsearch cluster behind the FIESP data breach exposed RG and CPF numbers—Brazil's national ID and taxpayer numbers—for more than 34 million people.

Who Was Actually Running This Database?

The database's structure pointed away from AmEx's own core infrastructure. Field names like "campaignID," "prequalstatus," and "leadID" suggested this was run by a third-party subcontractor handling SEO or lead-generation work for American Express India, rather than a system AmEx itself built and operated. That distinction doesn't reduce the exposure—Aadhaar and PAN numbers tied to a major financial brand are just as sensitive regardless of which vendor mishandled them—but it does point to where the actual failure happened: in a marketing or lead-generation pipeline sitting several steps removed from the bank's own security team.

Contact and lead data was a recurring weak point that autumn. Earlier the same month, researchers had found 66 million scraped LinkedIn profile records in an unsecured MongoDB whose owner was never identified, and roughly two weeks after the AmEx India find, an unprotected database at B2B contact-data provider Adapt.io exposed 9.3 million business contact records. Sales and marketing data tends to get copied, enriched, and handed between vendors, and every hand-off is another place for it to end up on an open server.

American Express's Response

After notification, American Express's incident response team secured the database. The company's public position was that the MongoDB itself was "securely encrypted" and that it had found no evidence of unauthorized access to the environment. That statement sits somewhat awkwardly next to the facts: one collection (689,272 records) was explicitly unencrypted, and the linked files on AmEx's own website holding PAN and mobile numbers were plaintext as well. "The database was encrypted" doesn't mean much when a meaningful share of the exposed data wasn't.

What This Means Under India's DPDP Act Today

India didn't have a dedicated data protection law in 2018—the closest equivalent was a narrower provision in the 2011 IT Rules covering "sensitive personal data." That's changed on paper, though not yet fully in practice. India's Digital Personal Data Protection Act (DPDP Act) was passed in August 2023, and its implementing rules were finally notified in November 2025—more than two years later. Enforcement is being phased in deliberately: the Data Protection Board itself and its investigative powers are active now, but the substantive provisions that would have actually governed an incident like this one—breach notification requirements, mandatory security safeguards, and the penalty structure tied to them—don't take legal effect until May 2027.

So the honest answer for "would this trigger DPDP consequences today" is: not quite yet, but soon, and the shape of those consequences is already defined. Once the Act's security and breach provisions are binding, any personal data breach—no materiality threshold required—will require notifying affected individuals "without delay" and notifying India's Data Protection Board within 72 hours. Penalties for inadequate security safeguards leading to a breach can reach ₹250 crore (roughly $30 million) per incident, with a separate penalty of up to ₹200 crore for failing to notify. Critically, a data fiduciary like American Express doesn't get to point at a subcontractor and walk away—under DPDP, the fiduciary remains responsible for how its processors handle personal data. There's no public DPDP enforcement track record yet to point to as a concrete comparison, since the Board's penalty powers aren't active—but the liability a comparable 2027-and-beyond incident would face is no longer hypothetical in the way it was in 2018.

Is This Still Happening? Aadhaar and PAN Exposure in 2026

Unsecured cloud storage exposing Aadhaar and PAN data hasn't gone away. In December 2024, researchers found an unsecured AWS S3 bucket belonging to Indian fintech lender FatakPay exposing more than 27 million files—KYC documents, loan applications, PAN and Aadhaar identifiers, selfies, and credit reports—which had sat exposed since at least September 2024 before being secured. Separately, in April 2024, TechCrunch reported that a misconfigured Indian government cloud database had leaked Aadhaar numbers, passport data, and COVID vaccination records for years before an independent researcher's findings led to a fix. Neither case is an exact structural match for a marketing subcontractor running an exposed database for a major financial brand—but both confirm that unsecured cloud storage holding India's most sensitive identity document numbers remains a recurring, not isolated, failure mode. It's also not an India-specific or financial-sector-specific one: the same unauthenticated-database pattern surfaced in 202 million resumes left exposed in an unsecured MongoDB in China and in the millions of candidate records French job agency MisterTemp left open on Elasticsearch, both discovered the same way this one was.

Has American Express Had Other Security Incidents Since 2018?

Yes, and the pattern is notable: AmEx's own core systems have not been the headline vector again, but its edges—insiders and third-party vendors—have been repeatedly. In 2019, AmEx disclosed that an employee had improperly accessed customer data, including Social Security numbers, in an apparent fraud attempt. In early 2024, a breach at a third-party merchant processor exposed cardholder names, account numbers, and expiration dates, with AmEx stating its own systems were not compromised. In June 2026, Australia's privacy regulator (OAIC) found American Express Australia had interfered with a customer's privacy by failing to take reasonable steps to protect their personal information from unauthorized internal access, ordering compensation, a written apology, and new access-logging controls. Each of these is a different failure mode than the 2018 MongoDB exposure, but they share a theme with it: the weak point kept being a person or a third party with access to AmEx customer data, not a direct attack on AmEx's primary infrastructure.

Does American Express Run a Bug Bounty Program Today?

Not that we could find. American Express's consumer-facing security center covers phishing and fraud reporting, not a vulnerability disclosure or bug bounty program. (A separate company, American Express Global Business Travel—only partly AmEx-branded and a distinct legal entity—does run its own VDP, but that shouldn't be mistaken for American Express itself having one.) For an organization that has now had its data exposed through a subcontractor, an employee, and a merchant processor across three separate incidents since 2018, the absence of a clear, incentivized channel for outside researchers to report what they find is a gap worth naming directly.

How to Secure Third-Party and Subcontractor Data Pipelines

The actual failure in this case wasn't inside American Express's own walls — it was in a vendor's database. That's a different problem to solve than securing your own infrastructure, and it takes different shapes: sometimes it's a vendor's own storage layer left open, the way Nokia's cloud environment was left exposed through an unsecured etcd server; sometimes it's a trusted third-party code library quietly carrying a vulnerability, as happened when an outdated charting library put 90-plus crypto exchanges at risk. Either way, the fix has to extend past your own perimeter:

• Require any vendor or subcontractor handling customer data—including marketing, lead-generation, and SEO vendors—to meet the same security baseline as your own systems, not a lighter one because the relationship feels lower-stakes.
• Audit what data a vendor actually needs before granting access; a lead-generation database rarely needs Aadhaar or PAN numbers, and collecting them anyway just expands what can leak.
• Treat encryption of one data store as incomplete if linked files, exports, or integrations elsewhere hold the same data in plaintext—as this case shows, attackers only need the weakest link.
• Regularly scan your own and your vendors' infrastructure with the same tools researchers and attackers use, including Shodan and Binaryedge, to catch an exposure before it's found by someone else.
• Establish a vulnerability disclosure or bug bounty program with a clear reporting channel, so a researcher who finds an exposure—in your systems or a vendor's—has an incentivized, legitimate way to tell you.

FAQ