Applebee's Android app shipped its database password, exposing customer records

A database password shipped to a million phones

Applebee's has fixed a flaw that left its customer database reachable by anyone willing to decompile the company's own Android app, which has more than a million downloads on Google Play. The credential was not stolen, phished or guessed. It was hardcoded inside the app itself.

According to TechCrunch, which published its report on October 30, 2026 after confirming the bug had been fixed, security researcher Robert Wiggins of What Security found the embedded credential earlier in the month by using an AI model to search thousands of lines of the app's decompiled code. TechCrunch verified the claim directly: it downloaded and decompiled the app, confirmed the credential was present, created an account with dummy data, and watched Wiggins pull that dummy record back out of Applebee's database. Per the researcher, the access allowed modification of records, not just reading.

What the database held

Per TechCrunch's account, ten field types were exposed: name, email, email verification status, date of birth, phone number, ZIP code, veteran status, login counts, account creation date and the IP address of the most recent login, a field that effectively reveals approximate location. No payment card data appears in the report. As a dev.to analysis of the incident notes, that makes this an identity-theft-grade record set rather than a card-fraud one: date of birth, phone, ZIP and email together are most of what an account-takeover attempt needs as a starting point.

The number of customers actually affected is unknown, and from the outside, unknowable. Wiggins deliberately declined to count records, because counting would have meant touching every customer entry. Applebee's had at least 8.5 million rewards members as of last year, but the company would not say how many customers' data was exposed. The dev.to write-up offers rough framing for the potential surface: even 1% of that rewards base would be 85,000 records.

A disclosure with no front door

Dine Brands, Applebee's parent company, said its security team has so far found no evidence of unauthorized access. But when TechCrunch asked whether the company has server logs it could review to determine past access, a spokesperson would not say. A denial from a company that will not confirm reviewable logs exist cannot demonstrate that nobody got in; it can only show that nobody has checked.

The disclosure path is its own indictment. Wiggins could not alert Applebee's or Dine Brands directly, because neither company offers a way to report security issues. He had to route the finding through TechCrunch. A public company with millions of loyalty members and no vulnerability reporting channel did not simply have one bad day; it had a standing gap that this incident slipped straight through.

The oldest root cause in the book

The underlying mistake is ancient: treating a mobile app as a trusted client. Anything compiled into a shipped APK, whether a password, a private key or a database credential, is public the moment the app is published, because decompiling an APK is routine work, not an attack. The dev.to analysis stresses that hiding the string better is not a fix: obfuscation, string splitting and native-code storage only delay the same decompiler by minutes. The real fix is architectural. The app talks to an API, the API authenticates the user, and the database credential lives server-side, where no user ever sees it.

The AI angle deserves note without exaggeration. AI did not create this vulnerability; it made finding it cheap. A researcher pointed a model at thousands of lines of decompiled code and asked it to locate the credential. Every team shipping a mobile app should now assume that search costs roughly nothing and run it on their own release artifacts first. A secrets scan in CI would plausibly have caught a database password sitting in a build.

Why it matters

This incident is instructive precisely because nothing exotic happened. There was no zero-day and no supply-chain compromise, just a credential placed where credentials should never go and then distributed to over a million devices. The exposed data is well suited to identity theft and account takeover, the veteran status field carries its own sensitivity, and the company cannot currently demonstrate whether anyone actually used the access. The questions TechCrunch left unanswered are the ones that matter: whether Dine Brands notifies customers or files anything with the SEC, and how long the credential sat in the app. Duration is the single number that would turn exposure into a measurable blast radius, and it is the number the company has so far declined to give. For everyone else shipping apps, the checklist is short: assume your binary is public, scan release artifacts for secrets, keep database credentials server-side, and publish a way for researchers to reach you.