How Fiverr's Public URLs Put 30,000 Documents on Google

In early March 2026, a security researcher going by “Morpheuskafka” typed a handful of Google search operators targeting fiverr-res.cloudinary.com and watched something unusual come back: freelancers’ tax returns, driver’s licenses, passports, and signed contracts sitting in open search results. Thirty thousand of them, publicly readable, all indexed by Google.

The researcher reported the findings to Fiverr’s security team. Fiverr didn’t respond. Forty days later, on April 15, 2026, Morpheuskafka published the findings publicly. Fiverr’s official position: “this is not a cyber incident.”

That framing is worth spending some time on.

What happened

Fiverr uses Cloudinary, a popular third-party media and document platform, to handle files shared through its built-in messaging system. Clients and freelancers exchange documents through that system regularly: compliance materials, identity verification, signed agreements, tax forms. The problem wasn’t with Cloudinary itself. It was how Fiverr configured it.

Cloud media platforms like Cloudinary offer two broad URL models. Signed URLs attach a time-limited signature that expires, so a link to a document stops working after a set period. Public URLs are permanent and, unless you explicitly block crawlers, are fully discoverable by search engines. Fiverr chose public URLs for its document delivery.

The result: every document shared through Fiverr’s messaging interface got a permanent, crawlable link on a Cloudinary subdomain. Google’s crawlers did what they do. They indexed the links. A researcher with the right search operators could pull up tax returns bearing Social Security numbers, government-issued ID documents, passports, API keys, and contracts. Cybernews, which covered the story after the researcher went public, put the count at over 30,000 distinct documents indexed. Privacy Guides, SC Media, and Inc. Magazine confirmed the exposure independently.

The documents weren’t buried or encrypted at rest in a way that required a technical bypass. They were retrievable via a targeted site: query.

flowchart LR
    User["Freelancer or client"] -->|uploads document| Fiverr["Fiverr messaging"]
    Fiverr -->|stores file| Cloudinary["fiverr-res.cloudinary.com<br/>(permanent public URL)"]
    Cloudinary -->|crawled| Google[(Google index)]
    Google -->|site: query| Anyone["Anyone with a search box"]

Why the framing matters

Fiverr’s response is worth examining carefully. The company said the documents had been “shared by users in the normal course of marketplace activity to showcase work samples, under agreements and approvals between buyers and sellers.”

That statement is accurate in a narrow sense. Users did upload these documents. They uploaded them to share with specific counterparties: a client asking for identity verification, a buyer requesting a signed agreement. That’s a controlled disclosure to one person. It isn’t consent to have those documents permanently indexed and retrievable by Google search.

The gap between “the user uploaded this” and “the user agreed to public indexing” is the entire privacy issue here. It’s a familiar failure mode in platform thinking. Users share data in a specific context (a direct message to a client) and the platform treats that as permission to handle the data however its infrastructure defaults. No one creating a Fiverr account expects their tax documents to be findable via a Google search.

Security researchers who reviewed the issue were more direct. Cybernews quoted experts describing it as “a major security lapse,” noting that using permanent public URLs for sensitive user communications is a well-understood anti-pattern in cloud storage security. The fix (switching to signed, expiring URLs) is not technically difficult. It’s a configuration choice Fiverr didn’t make.

The documents themselves

What makes this exposure land harder than a typical credential leak is the kind of documents involved.

Tax forms with Social Security numbers, passports, driver’s licenses, signed contracts. These aren’t credentials you can rotate. There’s no “change your passport” option, and SSNs are used for identity verification for years or decades. A driver’s license image is a persistent piece of identity that can enable fraud long after the original exposure is remediated.

Freelancers on Fiverr are routinely asked to provide these documents as part of compliance workflows. Clients purchasing certain services from US-based workers often request tax documentation so they can report payments accurately to the IRS. The worker submits a W-9 or similar form through the platform. The platform stores it. And if the platform’s storage configuration isn’t right, it ends up exactly where Morpheuskafka found it.

A W-9 specifically contains your legal name, address, and Social Security number (or EIN if you’re incorporated). The confirmed presence of tax forms with SSNs in the exposed set suggests tax compliance documents were part of the exposure, though public reporting hasn’t fully enumerated every document category involved. If you submitted tax documentation through Fiverr’s messaging interface, the assumption that those materials were handled privately was reasonable. It wasn’t necessarily warranted.

What it means if you’ve used Fiverr

Fiverr hasn’t published a public post-incident report. The company’s statements suggest some steps have been taken to address the indexing, and some previously discoverable URLs appear to have been removed or restricted. But Google’s cache and third-party crawlers may have already preserved copies of documents that were indexed before Fiverr acted. The practical exposure for affected users could persist regardless of what Fiverr does with its CDN configuration going forward.

If you’ve submitted tax forms, ID documents, or signed contracts through Fiverr’s messaging system, it’s worth checking whether those documents remain discoverable. A targeted search using your name alongside the Cloudinary subdomain Fiverr uses may surface any still-indexed files. Whether copies have already been saved to other locations is harder to determine.

More broadly: platforms that collect sensitive documents through their messaging or compliance workflows are making storage decisions that users can’t see or audit. Signed URLs, expiring access tokens, access control policies, crawler directives. These are real choices that directly affect the privacy of the documents you submit, and you generally have no visibility into any of them at the time you click “send.”

The configuration problem isn’t unique to Fiverr

Fiverr uses Cloudinary. Many other gig platforms, marketplaces, and SaaS products use similar cloud media services. The signed-URL pattern is well-documented and widely supported in every major cloud storage and CDN system. The failure here was a configuration choice, not an inherent flaw in any underlying technology.

That’s actually the more unsettling finding in this story. Fiverr isn’t unusual because it used third-party cloud storage for user files. It’s potentially not unique in its configuration either. Other platforms may be using similar setups for documents their users believe are private. The technique Morpheuskafka used (targeted search operator queries against a CDN subdomain) requires a search box and knowledge of the platform’s domain structure, not a vulnerability scanner. It’s reproducible.

The question of whether it’s safe to share documents online often focuses on the signing mechanism itself: the cryptographic validity of the signature, the audit trail, the authentication of parties. Those things matter. But this incident points to something that comes after all of that: where the document lives once you’ve submitted it, and who can reach it there.

Reducing the surface area

For people thinking about how to shrink this kind of exposure, one category worth knowing about is tools that don’t retain a copy of your document at all. Firefox’s built-in PDF viewer supports basic annotation and signing. macOS Preview handles signatures locally without sending anything to a server. Tools that use a no-upload signing approach process documents locally in the browser, so there’s no copy on a third-party server that could be misconfigured. Open-source options like OpenSign can be self-hosted, putting storage configuration under your own control.

None of these changes what clients can require you to submit through their preferred platform. But for the document handling you do control, including preparing and signing contracts before you submit them anywhere, keeping sensitive files off third-party servers removes the specific failure mode Fiverr hit: a document you believed was private sitting on someone else’s server with the wrong access policy applied.

What comes next

Fiverr’s 40-day non-response to the researcher’s initial disclosure is itself a data point about how some platforms handle inbound security reports. There’s no public indication that a formal policy change has been announced or that Fiverr has committed to a timeline for publishing a root-cause analysis.

The more interesting question is whether this prompts scrutiny of similar configurations elsewhere. The technique Morpheuskafka used is documented and reproducible. If security researchers start running similar queries against other gig economy platforms, the Fiverr exposure may turn out to be one entry in a longer list found this year. Thirty thousand documents is the number that Google had indexed at the time of public reporting. Whether the full scope of the exposure is larger isn’t known.

The practical thing to watch for: a platform publishing a meaningful post-incident report, including what configuration was in place, when it changed, and what monitoring would catch this class of issue in the future. If Fiverr does that, it’ll be worth reading. If it doesn’t, that absence is informative too.