Tools / News / 30,000 Tax Returns, IDs, and Contracts: Fiverr's Private User Files Found on Google Search
Press

30,000 Tax Returns, IDs, and Contracts: Fiverr's Private User Files Found on Google Search

· VaultTools

A security researcher disclosed on April 16, 2026 that Fiverr stored user-uploaded PDFs on Cloudinary behind unauthenticated, non-expiring URLs. Tax forms, driver's licenses, health records, and admin credentials were indexed by Google Search. Fiverr was notified 40 days earlier and did not respond. The company denies it is a cyber incident.

VaultTools · April 21, 2026

A person typing on a laptop with lines of code visible on the screen, representing cloud storage URLs that were indexed by search engines. Photo on Unsplash

Table of Contents

What Happened

On April 16, 2026, an anonymous security researcher using the handle Morpheuskafka published findings on Hacker News showing that private documents uploaded to Fiverr were accessible through Google Search. Cybernews and several other outlets independently confirmed the claims the same day.

The documents were not stolen in a breach. They were stored in Fiverr’s Cloudinary account, a third-party media service the platform uses to host PDFs and images exchanged between buyers and sellers. Fiverr configured those files behind unauthenticated, non-expiring public URLs, and Google Search crawled and indexed them. A query such as site:fiverr-res.cloudinary.com form 1040 returned thousands of results at the time of disclosure.

SecurityOnline and Sentra reported that more than 30,000 private documents were exposed. Files remained accessible for weeks after the initial private disclosure and for hours after public reporting began.

What Leaked

The exposed documents included tax forms such as Form 1040 (U.S. individual income tax return), passports, driver’s licenses, national ID cards, private work contracts and deliverables, invoices containing home addresses, health records, passwords, API keys, and at least one set of admin credentials.

Cybernews noted that some files revealed business-to-business agreements, unreleased design work, and personal correspondence. Sentra’s analysis found that the scope spanned regulated categories including tax information and protected health data, which fall under U.S. IRS and HIPAA requirements respectively.

One detail stood out. Fiverr was paying for Google Ads targeting the keyword “form 1040 filing” while the tax forms its own users had uploaded were, on the same search engine, publicly indexed.

How a Misconfiguration Became a Public Archive

Cloudinary supports signed URLs, expiring URLs, and access-control rules. Fiverr chose none of these for the documents in question. Instead, files uploaded in chat threads received permanent public URLs that were then embedded in HTML pages Google could reach.

David Stuart of Sentra described the root cause as “a failure to understand where regulated data lives, how it rapidly proliferates and is shared across services, and whether controls like signed URLs, authentication, and proper indexing rules are actually in place.” He added that the incident was not a zero-day exploit but a gap in configuration hygiene.

Privacy Guides reported a related finding during the disclosure period. Fiverr’s ISO 27001 information security certification had expired, a detail that does not prove negligence on its own but contradicts the platform’s marketing of robust data handling.

Disclosure Timeline and Fiverr’s Response

According to the researcher’s post, Fiverr’s security team was notified by email approximately 40 days before public disclosure. The researcher reported no substantive response during that window. Only after Cybernews and Inc. contacted the company did Fiverr issue a statement.

Fiverr’s statement read: “To be clear, this is not a cyber incident. Fiverr does not proactively expose users’ private information. The content in question was shared by users in the normal course of marketplace activity to showcase work samples, under agreements and approvals between buyers and sellers.”

The statement reframes the exposure as intended user behavior rather than a configuration error. It does not address the indexing of tax returns, passports, or admin credentials, documents that no seller would reasonably share as a “work sample.” At the time of reporting, the public URLs were still resolving for some files.

Why Uploaded Files Are a Structural Risk

The Fiverr incident is not about a sophisticated attacker. It is about what happens when a file leaves a user’s device and enters a third-party pipeline. Once that PDF is uploaded, the user no longer controls whether it is stored with signed URLs, whether it is indexed, whether the storage vendor is itself breached, or whether the host’s compliance certifications are current.

Privacy Guides made the same observation in its coverage: “If you don’t upload it, it can’t be exposed.”

This is the structural argument for running file operations in the browser. A PDF merged, split, compressed, or watermarked inside a WebAssembly module stays on the user’s machine. There is no cloud bucket, no signed-URL policy to misconfigure, and no search engine crawler reaching the file. The data never enters a third party’s environment at all.

VaultTools runs every tool in the browser using Rust compiled to WebAssembly. Files are read into memory, processed by the Wasm module, and returned as a download. No network request carries the file contents. The Fiverr exposure is a reminder that the safest file is the one that was never uploaded.

Sources

← Back to all news