Skip to main content
Recent cloud data exposure incidents like Fiverr’s highlight a growing problem with third-party cloud storage. Last week, Fiverr made headlines when researchers discovered that sensitive user files — tax forms, government IDs, invoices, contracts, and other personally identifiable information — were left publicly accessible via direct URLs on a third-party cloud storage provider (Cloudinary). Google had already indexed many of these files, making them searchable by anyone.

This isn’t an isolated mistake. It’s a pattern we see repeated around the world, month after month.

 

Why Cloud Data Exposure Incidents Keep Happening

Most organizations rely on third-party processors and cloud storage platforms (AWS S3, Google Cloud Storage, Azure Blob, Cloudinary, Firebase, etc.) to handle their data. While in-transit encryption (TLS/HTTPS) is now standard and protects data while it moves across the internet, the real vulnerability almost always sits at the storage layer — what security experts call “encryption at rest.”

Common root causes include:

 

    • Buckets or folders left public or with overly permissive access policies
    • Non-expiring signed URLs that never require re-authentication
    • Server-side encryption where the cloud provider holds the keys
    • No client-side encryption at the application level

cloud data exposure protected by P3E client-side encryption
 
The result is another preventable cloud data exposure that leaves sensitive data wide open to search engines and attackers.

Recent Cloud Data Exposure Examples (2025–2026)

  • IMDataCenter (August 2025): IMDataCenter (A Florida-based data broker / marketing data provider) exposed client data belonging to organizations in healthcare, insurance, political campaigns, airlines, universities, and car dealerships. Exposed data included names, email addresses, and ownership details.

Specific client company names were not publicly disclosed by researchers (to protect privacy). One client that publicly issued breach notices to individuals: Apex Class Action.

  • 149 million credential database (January 2026): A 96 GB unsecured database containing millions of Gmail, Facebook, banking, and other login credentials was left completely open on the internet — no password, no encryption.

This was not a breach of one company’s systems. Rather it contained user credentials stolen from millions of individuals across many services:

  1. 48 million Gmail
  2. 17 million Facebook
  3. 5 million Instagram
  4. Millions more for Netflix, Yahoo, banking/credit-card logins, Biance (crypto), etc. Some .gov and government-system credentials from multiple countries were also exposed.

 

  • Ongoing S3 bucket campaigns and healthcare/banking exposures: Hundreds of thousands of patient records, bank transfer documents, and corporate files continue to surface through similar cloud misconfigurations rather than one coordinated “campaign”. Notable public examples include:
    • Healthcare: ESHYFT (New Jersey HealthTech staffing – 86K+ staff records, Mar 2025); Archer Health (California home health/palliative care – patient records, Sep 2025)
    • Banking/Financial Services: Navy Federal Credit Union (world’s largest U.S. credit union serving military/veterans – 378 GB internal backups, Sep 2025); Plus a large Indian financial-services case (~273K bank-transfer PDFs affecting dozens of Indian banks/fintech firms via Nupay, Aug/Sep 2025).

Gartner has warned for years that 99% of cloud security failures will be the customer’s (or their vendor’s) fault due to misconfigurations — and the data bears this out.

Fiverr cloud data exposure fixed with P3E encryption

The real solution: Encrypt at the source with P3E

At Global Integrity Inc., we built P3E (Polymorphic Encryption) specifically to solve this exact problem.

Unlike traditional server-side encryption, P3E is:

  • Client-side and application-level — the data is encrypted before it ever leaves your environment
  • True end-to-end — even the third-party processor or cloud provider cannot read it
  • Polymorphic and quantum-resistant — every file, message, or record uses unique, dynamic encryption keys that change with each use
  • Zero-trust by design — a public URL or leaked bucket simply points to useless ciphertext

Your sensitive files stay protected even if Google indexes them, a vendor bucket goes public, or an insider (or attacker) gains access to the storage layer.

Bottom line

In-transit encryption is table stakes. True security today requires encryption at rest that you control — before the data ever touches a third-party processor.

If your organization handles PII, financial documents, healthcare records, or any sensitive data in the cloud, now is the time to move beyond hoping your vendors get the configuration right.

Ready to see how P3E can make your data exposure-proof even when third parties fail?

Visit us at globalintegrity.com, or schedule a demo http://calendly.com/globalintegrity/qtel