I was recently included in IBD’s 2026 Coordinated Vulnerability Disclosure Hall of Fame for a responsible disclosure report involving an exposed Firebase Realtime Database. What made this case notable was not only the exposure itself, but also how quickly the issue was handled after disclosure.
During research into publicly exposed Firebase instances, I identified a Firebase Realtime Database belonging to a Dutch municipality that allowed unauthenticated read access.
The database could be verified in two straightforward steps.
First, the structure could be enumerated using the shallow=true parameter:
https://[redacted].firebaseio.com/.json?shallow=true
This made it possible to inspect the top-level keys without retrieving the full dataset.
Second, a standard GET request to the root returned the entire database contents as JSON:
https://[redacted].firebaseio.com/.json
In this case, the response was approximately 150 MB.
The exposed database contained 40.000 records and multiple categories of operational and personal data, including:
- citizen reports
- survey data
- PII of citizens
- names
- email addresses
- phone phone numbers
- address details
- servicedesk-related information
This type of exposure is typically caused by overly permissive or missing Firebase Security Rules. In this case, the database appeared to allow public read access because authentication restrictions had not been properly enforced.
Rather than trying to contact the municipality directly, I reported the issue through the municipal security coordination channel at:
incident@ibdgemeenten.nl
That mailbox is worth highlighting. In the report, I included a concise technical description, reproduction steps, the affected endpoint, a summary of the exposed data, and a recommendation to immediately restrict unauthenticated access through Firebase Security Rules.
The turnaround was unusually fast!
The report was acknowledged 16 minutes after submission and forwarded to the relevant party for remediation. Within a few hours, public access had already been disabled.
After the fix, requests to the database no longer returned data and instead produced the expected authorization failure:
{
"error": "Permission denied"
}
From a technical disclosure perspective, this was a strong example of efficient coordination between the disclosure handler, the affected organization, and the supplier responsible for remediation.
Cases like this are often discussed purely in terms of exposure, but response quality is just as important.
An exposed cloud database is rarely a complicated finding from a technical perspective. The real differentiator is how quickly the issue is assessed, escalated, and fixed. In this case, the vulnerable configuration was removed quickly enough to significantly reduce the exposure window.
That is exactly what coordinated vulnerability disclosure should achieve: clear reporting, prompt validation, and immediate corrective action. This case was a good example of why responsible disclosure processes matter, and why fast operational response matters even more.