A delivery app left its backend wide open: the FLY Firebase dump and what dark-web buyers pay for cloud mistakes
Not every dark-web listing starts with an intrusion. A growing share starts with somebody forgetting to switch on authentication. This month that pattern produced one of the larger claims of 2026: a seller advertising what they describe as a complete extraction of the production backend of FLY (flyfly.co.kr), a Korean food-delivery platform, pulled through a Firebase configuration that allegedly allowed anonymous read and write access to everyone.
What the seller claims
According to SOCRadar's Dark Web Team, the listing claims 47.9 million records totalling 46.6GB were extracted from the production backend between August 13 and August 14, 2026, because Firebase security rules were absent entirely — leaving Firestore and Cloud Storage readable and writable without any credentials. The claimed dataset is unusually broad even by breach standards: customer orders with GPS coordinates and apartment door codes, rider profiles pairing Korean Resident Registration Numbers with plaintext passwords and bank account details, restaurant identity records, and live payment-gateway API keys for thousands of merchants. The claim remains unverified. As Dark Web Informer noted in its analysis, the samples are internally consistent with a Firestore export, but row counts and pricing come entirely from the seller, whose forum account is only weeks old, and neither the platform operator nor Korean authorities had publicly addressed the claim at the time of writing. Treat every number here as alleged until confirmed. Why write access matters more than read access
Most coverage of open databases focuses on what leaked out. The more disturbing part of this claim is the alleged write access. A readable backend exposes people; a writable one lets whoever finds it change records, alter delivery destinations, or redirect payment details while the exposure lasts. Until the rules were fixed and every embedded credential rotated, anyone who discovered the endpoint held something closer to administrative control of the platform than a copy of it. That distinction — snapshot versus standing access — is what separates an embarrassing leak from a live operational risk, and it applies equally to any self-hosted service exposed to the public internet. One report, four listings, three price tags
The same SOCRadar report documents how routine these listings have become. Alongside the FLY claim, sellers advertised RDWeb remote-desktop access to an Italian cloud and IT services provider at an auction starting at $1,200; a database attributed to South Africa's Green Building Council with 500,000 records of names, contact details, and demographic information priced at $500; and a BullyPedex.com customer dataset of more than 280,000 records offered at $800. Each carries the standard disclaimer — alleged, unconfirmed, seller-sourced — but together they sketch the current market clearly: initial access sells for four figures, mid-sized personal datasets for three. The pricing tells you what buyers think they are getting. Access sales are valued per capability: an RDWeb foothold can be resold, ransomed, or used to stage further compromise, so bidders treat it like inventory. Data sales are valued per exploitability. Records combining government identity numbers, plaintext passwords, and bank accounts command attention because they enable account takeover, loan fraud, and highly convincing phishing in one purchase — which is why the same hygiene failures keep paying out twice, first to the finder and then to every downstream buyer. Misconfiguration as the top supply line
Security teams tend to picture breaches as exploitation of exotic vulnerabilities. The bulk of dark-web data inventory traces back to something far duller: cloud storage and database services configured incorrectly. Researchers repeatedly find tens of thousands of open Firebase instances, S3 buckets, and similar endpoints through nothing more than systematic scanning — one recent analysis documented over 150 popular apps exposing sensitive data through Firebase misconfiguration alone. No exploit code, no zero-days, no malware. Just defaults nobody changed and rules nobody wrote. For buyers, misconfigured storage has two attractive properties. It scales — scanning tools enumerate thousands of candidates automatically — and it is cheap to monetise quickly, since an open bucket can close at any moment and sellers list within hours of discovery. The FLY listing was reportedly posted hours after the newest records it contained. Speed is the whole business model. What actually closes this channel
The fixes are unglamorous and mostly free: enforce authentication on every database and bucket, default-deny security rules, block public access unless a specific feature requires it, scan your own infrastructure the way researchers do, rotate API keys on schedule so an exposed key dies fast rather than living forever. For users, the takeaway is less controllable — you cannot configure someone else's Firebase — which is why reuse across services is such a liability when dumps like this surface. If your password appears in one platform's plaintext leak, everything it unlocks is at risk; our earlier piece on unique logins and password hygiene covers why per-site credentials remain the cheapest defence against exactly this class of event. The FLY claim may yet collapse under scrutiny, like many listings do. But the mechanism it describes will not go away. As long as anonymous access to production data costs a seller nothing and earns them tens of thousands of dollars, misconfiguration will keep topping the dark web's supply chain — and the price lists above are simply what the market currently pays for other people's forgotten settings.
