Fiverr Left Customer Files Public and Searchable on Cloudinary
2 min read
Originally from news.ycombinator.com
View source
My notes
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
[email protected]; 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.