# Fiverr Left Customer Files Public and Searchable on Cloudinary

> Fiverr served client file attachments via Cloudinary public URLs, letting Google index tax returns, API tokens, and health records. 40 days unanswered.

Published: 2026-04-16
URL: https://daniliants.com/insights/tell-hn-fiverr-left-customer-files-public-and-searchable/
Tags: cloud-storage, data-leaks, security, cloudinary, responsible-disclosure, configuration-defaults

---

## Summary

Fiverr served client-worker file attachments through Cloudinary using public URLs instead of signed/expiring ones, resulting in hundreds of sensitive documents (tax returns, API tokens, pen-test reports, health records) being indexed by Google and searchable via queries like `site:fiverr-res.cloudinary.com form 1040`. The report went unanswered for 40 days before being disclosed publicly. Fiverr continued buying Google Ads for tax-prep keywords while knowingly violating the GLBA/FTC Safeguards Rule.

## Key Insight

- The failure wasn't a zero-day or novel attack, it was a configuration default. Cloudinary supports signed/expiring URLs (like S3 presigned URLs) but they must be opted into. Any engineer assembling a file-delivery path on a CDN who picks "fastest to ship" ends up here.
- "Public by default" + server-rendered HTML that links to the asset URLs = Google indexes everything. This is how most of these leaks actually surface: the files aren't linked in brute-force tests, they're linked in listing or preview pages the ops team forgot were public.
- Responsible disclosure channels are routinely broken. 40 days of silence from `security@fiverr.com`; when a second reporter pinged them during the HN thread they replied they had "no record" of the original report. Absence of acknowledgment is not absence of the report, it's a broken inbox or a triage process that drops first-time reporters.
- Regulatory exposure is real and specific: in the US, tax-prep work puts the processor under the GLBA/FTC Safeguards Rule (16 CFR 314) and the IRS Publication 4557. Leaking a Form 1040 isn't a "data breach" abstractly, it's an enumerated compliance violation per file.
- Subprocessor risk: Cloudinary is the host, Fiverr is the controller. Enterprise CDN contracts rarely include alerting on "your customer has 10k+ PII-shaped PDFs exposed to anonymous GET." That detection has to live with the controller, and clearly didn't.
- Takedown is slow by design: even after the HN post, files stayed indexed for hours. DMCA notices had been filed months earlier (lumendatabase notice 53130362) and ignored. If you're the controller of an S3-style bucket, "block all anonymous access at the CDN edge" is a 5-minute change, not making it means no one on the on-call rotation has that authority or the muscle memory.
- Meta-lesson for anyone running a gig/work marketplace: messaging attachments are PII by definition (contracts, IDs, tax forms, medical). Treat the attachment bucket like a payments system, not like avatar uploads.