CyphrQ
Menu

Chat & Ask AI Data Leak: 300 Million Messages, One Firebase Error

A researcher says a Firebase error left about 300 million Chat & Ask AI messages readable. What is confirmed, what is not, and what to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: January 202610 min read

What was the Chat & Ask AI data leak? An independent security researcher, who goes by Harry, says a misconfigured Firebase backend behind the Chat & Ask AI app left about 300 million messages from more than 25 million users readable. This was a configuration error, not a hack: nobody broke in, the door was open. The sources I read report no confirmed misuse, but none can rule it out.

This is a case file. It sets out what the researcher and the press report, what the developer has and has not said, and what to check if your team uses AI apps or builds them.

Case file

Field Value
App Chat & Ask AI, a "wrapper" app that connects to models from OpenAI, Anthropic and Google (Malwarebytes)
Developer Codeway. The App Store seller is listed as Deep Flow Software Services-FZCO (Macworld)
Discovered by An independent researcher known as "Harry" (X handle Harrris0n, per Macworld)
Timing Registry entry dated 15 January 2026; researcher's X post saying the problem was addressed dated 20 January 2026 (both per Macworld). 404 Media's report published 29 January 2026
Cause Misconfiguration of Google Firebase, the app-development platform (404 Media)
Size, as the researcher states it "300 million messages from more than 25 million users" (404 Media)
What he examined A sample of about 60,000 users and one million messages (404 Media)
Data types Complete chat histories, timestamps, chatbot names, model configurations, and which model each user chose (404 Media)
Developer statement I could not find one in my sources
Misuse Not reported as confirmed in the sources I read
Status Reported fixed. Malwarebytes says Codeway "reportedly resolved the issue across all of its apps within hours of responsible disclosure"

How did the Chat & Ask AI database exposure happen?

It was a configuration mistake. Firebase is a Google service that gives mobile apps a ready-made backend: a database, file storage and sign-in. The app talks to it directly, so a set of access rules decides who can read what.

404 Media, which broke the story on 29 January 2026, describes "a misconfiguration in the app's usage of the mobile app development platform Google Firebase" (404 Media). Its account is that the setup let anyone make themselves an "authenticated" user and then reach the backend storage.

Malwarebytes describes the cause more generally. It calls it "a well-known and documented Firebase misconfiguration" and says one of the most common is leaving security rules public, which "allows anyone with the project URL to read, modify, or delete data without authentication" (Malwarebytes).

The two descriptions differ in detail: one says a sign-in step existed but was open to anyone, the other says no sign-in was needed. I have not seen Codeway's actual rules, so I can't say which is exact. Both describe the same class of error, and the fix is the same.

How many Chat & Ask AI messages and users were exposed?

The figures come from the researcher, and the press repeats them as his claim. Malwarebytes writes that "the researcher claims to have accessed 300 million messages from over 25 million users" (Malwarebytes). It also says the app has more than 50 million users.

Figure Who states it Note
About 300 million messages The researcher, via 404 Media and Malwarebytes Not independently verified by me
More than 25 million users The researcher Same
About 60,000 users and one million messages The researcher, via 404 Media The sample he analysed
More than 406,000 files A public registry of exposed apps, as reported by Macworld A count of files, not messages. It is a different measure, so don't add it to the others

I round nothing up. "About 300 million" is the researcher's own phrasing. Codeway has not, in anything I found, confirmed or disputed the numbers.

What was inside the Chat & Ask AI data leak?

404 Media says the exposed data held full chat histories with timestamps, the names users gave their chatbots, model settings, and the model each person had picked. It also reports that some chats included suicide-related requests and a request for how to make methamphetamine (404 Media). Malwarebytes adds that data from users of other Codeway apps was also exposed.

A chat history is not a log of search terms. People type health worries, work documents and personal troubles into these apps because they feel private. That is why a leak of messages is more sensitive than the same number of rows of usage data.

Was the Chat & Ask AI data accessed by anyone else?

Not confirmed, and not ruled out. The researcher looked at the data and says so. None of the reports I read say that a criminal copied it, sold it or used it.

That is a statement about the reporting, not about what happened. Anyone who could reach the data the way the researcher did could have read it. Only Codeway's own logs could show who did, and I found no public statement from the company on whether it checked.

How did Codeway respond, and is it fixed?

The reporting says yes, with a gap in the timeline. Malwarebytes says Codeway "reportedly resolved the issue across all of its apps within hours of responsible disclosure". It adds that Codeway's apps were taken off the researcher's registry once the developers confirmed fixes.

Macworld, writing on 20 January 2026, noted a wrinkle: the researcher's post said the vulnerability "no longer exists", yet the App Store then showed a version of the app released on 7 January, before the registry entry of 15 January. Macworld concluded that the fixed version might not be public yet. That reads like a client-side release lag, since the rules live on the server. I treat it as unresolved.

I could not read the researcher's own post. It is on X, which would not load for me, and I found no separate write-up from him. So every figure here is as relayed by 404 Media, Malwarebytes and Macworld, not read at the source. If that changes, this page should be updated.

Is this part of a bigger pattern?

Yes, and it is the same shape as other recent AI leaks. Malwarebytes, citing 404 Media, says the researcher built a scanner for apps on Google Play and the Apple App Store, and that 103 of 200 iOS apps scanned had the same flaw. Whatever the exact count, it points to a common mistake across many small apps, not one careless team.

For a close parallel, see the 302.ai exposure of 2026, where an AI aggregator left chat logs in open cloud storage. Different platform, same lesson: the weak point is the storage behind the model, not the model.

Going deeper: for security and IT teams

Threat model. The actor needs a copy of the app, or its project identifier, and a way to get a valid session. What they get is whatever the rules allow a signed-in user to read. If the rules say "any signed-in user may read everything", the attacker's cost is one throwaway account. I am not describing discovery methods; the defensive point is that identifiers ship inside every app binary, so assume they are public.

How Firebase Security Rules work. The app calls the database or storage directly, with no server of your own in between. Firebase's documentation states the consequence: clients get direct access, and Security Rules "are the only safeguard blocking access for malicious users" (Firebase). The rules cover Cloud Firestore, Realtime Database and Cloud Storage, each with its own rules file, so a project can be tight in one and open in another.

Rules that fail. Two patterns matter here:

  • Test mode left on. Firebase's setup offers "allow anyone access (Test mode)" and warns that if you deploy, the data is publicly accessible "even if you haven't launched it".
  • request.auth != null. Firebase's own example allows reads and writes for "all authenticated users". It presents this as a development aid and says it does not recommend leaving data open to "any user that's signed in". The condition checks that someone is signed in, not that they own the data.

Controls, as Firebase documents them.

  • Initialise rules "in production or locked mode" so access is denied by default (Firebase security checklist).
  • Write ownership rules that compare the signed-in user's ID, request.auth.uid, with the owner of the document or path (Firebase). A chat belongs to one user; only that user should read it.
  • Do not let anonymous accounts count as real users. The checklist says "Anyone could create an anonymous account in your project", and advises rules that require users to have converted to a sign-in provider or verified their email.
  • Unit test rules with the Local Emulator Suite and run the tests in CI, so a loosened rule fails the build.
  • Enable Firebase App Check for every service that supports it, and set up monitoring and alerting on backend services.

Authorisation on backend APIs. If your app calls your own API instead, the same failure has a name: OWASP API1:2023, Broken Object Level Authorization. OWASP says every endpoint that takes an object ID and acts on it needs a check that "the logged-in user has access to perform the requested action on the record" (OWASP). It also warns that merely comparing the session's user ID with the ID parameter "isn't a sufficient solution". Use unpredictable record IDs, and write tests that fail the deployment when authorisation breaks.

What an AI wrapper app stores. From this case, a wrapper can hold full histories, timestamps, bot names, model settings and the chosen model, per 404 Media. Each is a field to classify. Decide which you need, how long you keep it, and who can read it. Retention is a design choice: delete or expire chats by default, and make deletion real in the backend, not just hidden in the app.

Detection and evidence. I have not tested Codeway's setup, so these are practitioner suggestions, not findings. Alert on one account reading many users' documents, on a sudden spike in reads, and on accounts created and used for bulk access within minutes. Keep access logs long enough to answer the question this case leaves open: who else read it? Test the control the way you would test any other, by trying to read another user's record with an ordinary account in a staging project.

What to ask a vendor. Are rules deny-by-default? Are they tested in CI? Are anonymous users excluded from reading others' data? What do you store per chat, and for how long? Can you show logs proving who accessed it?

What should you do if you use AI chat apps?

If you use a third-party AI app, treat anything you type as something the vendor may store. The AI at work privacy checklist lists what to keep out of chatbots.

  1. Do not put customer data, credentials or health details into AI wrapper apps that your organisation has not approved.
  2. Check what an app says it stores and whether you can delete your history.
  3. If you built or buy an app on Firebase, review the rules for each product it uses: Firestore, Realtime Database and Storage.
  4. Replace "any signed-in user" rules with per-user ownership rules, and test them.
  5. Ask vendors how they would tell you about an exposure, and how fast.

Learn more

Key takeaways

  • A researcher known as Harry says a Firebase misconfiguration left about 300 million Chat & Ask AI messages from more than 25 million users readable. Those are his figures, relayed by 404 Media and Malwarebytes.
  • This was a configuration error, not a hack. The press accounts differ on whether the rules were fully public or open to any self-made "authenticated" user.
  • Misuse has not been reported as confirmed in the sources I read. That is not proof it did not happen.
  • Codeway reportedly fixed the issue within hours of disclosure. I found no statement from the company.
  • I could not read the researcher's own post, so the figures here are second-hand and should be updated if he publishes a write-up.
  • Never leave rules at "any signed-in user". Use deny-by-default rules, per-user ownership, tests in CI, and short retention for chats.

Sources