In March 2024, three security researchers known as Logykk, xyzeva (Eva) and MrBruh reported that 916 websites had left their Google Firebase backends open to the internet. The sites either had no Firebase security rules or had set them up incorrectly, so anyone who found the project configuration could read the databases, and on most of them could also write. After scanning more than five million domains, the researchers counted more than 125 million user records, including about 106 million email addresses, 84 million names, 34 million phone numbers and 27 million billing records with bank details. They also found about 20 million passwords, 19.87 million of them stored in plaintext, even though Firebase provides an authentication service that avoids storing passwords at all. The research followed their earlier finding that a Firebase misconfiguration at Chattr, an AI hiring platform used by fast food chains, let them register an account and gain full database privileges. The researchers emailed 842 site owners; about a quarter fixed the problem. Google itself was not breached, and no misuse of the data was reported.
Key takeaways
- Researchers found 916 websites whose Firebase databases had missing or incorrect security rules.
- The exposed databases held more than 125 million user records and about 19.87 million plaintext passwords.
- Most of the affected sites also allowed anyone to write to the database, according to one researcher.
- Of 842 site owners notified, about a quarter fixed the misconfiguration and 1% replied.
- The identity lesson: a backend-as-a-service is only as private as its access rules, and a public client configuration plus open rules is an open database.
At a glance
| Organisations | Operators of 916 websites using Google Firebase; researchers Logykk, xyzeva and MrBruh |
|---|---|
| When | Research in early 2024; reported 19 March 2024 |
| Attacker | None known. Found by researchers |
| Entry point | Firebase databases with missing or misconfigured security rules |
| Identities abused | None confirmed; backend access controls allowed anonymous read and often write access |
| Impact | More than 125 million user records exposed, including about 19.87 million plaintext passwords |
| Category | NHI. Incident class: exposure (misconfigured cloud backends, no confirmed misuse) |
What happened
BleepingComputer reported that the three researchers "scanned more than five million domains and found 916 websites from organizations that either had no security rules enabled or had set them up incorrectly." Eva told BleepingComputer that the instances permitted read access to databases, and that "Most of the sites also had write enabled which is bad." For each exposed database, a script extracted a sample of 100 records to measure what was exposed. The totals were 84,221,169 names, 106,266,766 emails, 33,559,863 phone numbers, 20,185,831 passwords and 27,487,924 billing records. BleepingComputer added: "For passwords, the problem gets worse because 98% of them, or 19,867,627 to be exact, are in plain text."
The storage of plaintext passwords was a choice, not a platform default. Malwarebytes explained that Firebase "has a built-in end-to-end identity solution called Firebase Authentication" and that an administrator "would have to go out of their way and create an extra database field in order to store the passwords in plaintext." SecurityWeek named some of the affected sites, including Silid LMS, a learning platform exposing data on 27 million users, and an online gambling network of nine sites exposing about 8 million bank account details.
The project grew out of earlier work. SecurityWeek reported that at Chattr, "A weakness in Chattr's Firebase implementation allowed the researchers to gain full privileges to the database by registering a new user," and that Chattr fixed it on 10 January, a day after the report. For the wider scan, the researchers sent 842 emails over 13 days. BleepingComputer reported: "Although just 1% of the site owners replied, a quarter of the notified site administrators fixed the misconfiguration in their Firebase platform." GitGuardian commented that "if security researchers could easily uncover this many passwords, it is likely that malicious actors also discovered them."
Timeline
| Date | Event |
|---|---|
| 9 to 10 January 2024 | Researchers report the Chattr Firebase flaw; Chattr fixes it the next day. |
| Early 2024 | Researchers scan more than five million domains for exposed Firebase instances. |
| Before 19 March 2024 | Researchers send 842 notification emails over 13 days. |
| 19 March 2024 | BleepingComputer and SecurityWeek report the findings. |
How it happened: the identity attack path
- Public client configuration. Websites ship their Firebase project configuration in JavaScript, as designed.
- Missing access rules. Security rules were absent or misconfigured, so the backend did not check who was asking.
- Anonymous read and write. Anyone with the configuration could read, and often write, the databases.
- Sensitive data stored badly. Many apps kept user passwords in plaintext fields.
- Found at scale. Researchers scanned millions of domains and sampled the exposed databases.
Impact
- Exposed: more than 125 million user records across 916 websites.
- Passwords: about 19.87 million stored in plaintext.
- Remediation: about a quarter of notified site owners fixed the misconfiguration.
What this means for NHI governance
Most of the exposed data belonged to people, but the failure was in how applications controlled machine access to their backends. With Firebase, the client configuration and API key are meant to be public; the security rules are what decide who can read and write. When the rules are missing, every visitor, script or bot holding the public configuration gets the same access as the application itself.
The lesson applies to any backend-as-a-service: treat access rules as code, test them and review them before launch, and do not store secrets such as passwords where a rule mistake can expose them. See our API Key Management Guide and Authorisation Models Guide.
Recommendations
- Deny by default. Start Firebase security rules closed and open only what each user needs. See our Authorisation Models Guide.
- Test rules automatically. Run rule tests in CI and scan configuration for open access. See the ISPM Guide.
- Never store plaintext passwords. Use Firebase Authentication or salted hashes. See the Password Security Guide.
- Restrict public API keys. Limit keys to the domains and services they are meant for. See the API Key Management Guide.
- Act on researcher reports. Provide a security contact and respond quickly to disclosures.
Frequently asked questions
Was Google Firebase breached?
No. The researchers found websites that had configured their own Firebase security rules incorrectly. Google's platform was not compromised.
How many records were exposed?
More than 125 million user records across 916 websites, including about 19.87 million plaintext passwords, according to the researchers.
How were the databases exposed?
The sites had no security rules or incorrect ones, so anyone with the public Firebase configuration could read the data, and on most sites write to it.
Related NHI Mgmt Group resources
DeepSeek Database Exposure 2025 · Google API Keys Exposure 2026 · API Key Management Guide · Authorisation Models Guide · Password Security Guide
How NHI Mgmt Group can help
Cloud backends trust whatever their rules allow. We help teams review access rules, restrict public keys and find exposed data stores before others do. See our NHI and AI agent security training.
References
- BleepingComputer: Misconfigured Firebase instances leaked 19 million plaintext passwords (19 March 2024)
- SecurityWeek: Misconfigured Firebase Instances Expose 125 Million User Records (19 March 2024)
- GitGuardian: Misconfigurations in Google Firebase lead to over 19.8 million leaked secrets (20 March 2024)
- Malwarebytes: 19 million plaintext passwords exposed by incorrectly configured Firebase instances (21 March 2024)