Applebee's Android App 內藏資料庫密碼，持有 APK 者可讀取客戶資料

Applebee's shipped its database password inside its app. Anyone with the APK was an admin.

Applebee's fixed a flaw this week that let anyone read — and, per the researcher, modify — its customer database. The credential was not stolen, phished, or guessed. It was shipped inside the company's own Android app, which has more than a million downloads on Google Play.

TechCrunch published the story on October 30, 2026, after withholding it until the bug was confirmed fixed. Security researcher Robert Wiggins of What Security found it earlier this month, using AI to search through thousands of lines of the app's source code. TechCrunch independently verified it the way you would hope a newsroom verifies this kind of claim: it downloaded and decompiled the app, confirmed the credential was in the code, created an account with dummy data, and watched Wiggins pull that dummy record back out of the company's database.

What was exposed

Ten field types, per TechCrunch's account of the database:

exposed field types: 10
fields: name, email, email_verified, date_of_birth, phone, zip,
        veteran_status, login_count, account_created, last_login_ip
rewards members (lower bound, as of last year): 8.5M
app downloads on Google Play: >1M

Name, email, date of birth, phone, ZIP, veteran status, login counts, account creation dates, and the IP addresses of most recent logins — the last of which gives approximate location. No payment card data is listed in the report, and that matters: this is an identity-theft-grade record set, not a card-fraud one. Date of birth plus phone plus ZIP plus email is most of what an account-takeover attempt needs as a starting point.

How many customers were actually in the reachable database is unknown, and honestly unknowable from the outside. Wiggins declined to count records, because counting would have meant touching every customer record. 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. To size the surface without inventing a number: 1% of that rewards base would be 85,000 records; 10% would be 850,000. The point is not the percentage — it is that the denominator was "everyone the app could reach," and nobody can now say how many that was.

The part that should worry developers most

Dine Brands, Applebee's parent, said its security team "has not currently found any evidence of unauthorized access." Read the next sentence of the same report before taking comfort from that: when TechCrunch asked whether the company even has server logs it could review to determine past access, the spokesperson would not say. "No evidence of unauthorized access" from a company that will not confirm it has logs is not a finding. It is an absence of a finding, stated in the tone of a finding.

The second uncomfortable detail is how disclosure happened. Wiggins could not alert Applebee's or Dine Brands directly, because neither has a way to report security issues. He had to go through TechCrunch. A public company with 8.5 million rewards members and no vulnerability reporting channel is not a company that had one bad day; it is a company whose security posture has a hole shaped exactly like this incident.

And the root cause is the oldest one in the book, which is why I keep coming back to it. A mobile app is not a trusted client. Anything inside a shipped APK — a password, a private key, a database credential — is public the moment the app is published, because decompiling an APK is a routine operation, not an attack. I modeled the pattern locally to make the point concrete (no live system touched, the credential below is invented):

import re
fake_decompiled = 'DB_HOST="db.internal.example"; DB_USER="app_ro"; DB_PASSWORD="hunter2-not-real";'
m = re.search(r'DB_PASSWORD="([^"]+)"', fake_decompiled)
print("hardcoded credential extractable from shipped code:", bool(m))

hardcoded credential extractable from shipped code: True

The fix is not "hide the string better" — obfuscation, string splitting, and native-code storage all delay the same decompiler by minutes. The fix is architectural: the app talks to an API, the API authenticates the user, and the database credential lives server-side where the user never sees it. If your app binary contains a credential that grants more access than the user holding the phone should have, you do not have a secret. You have a public login, distributed to over a million devices, waiting for someone to read it.

That is also why the AI angle here is worth noting without overstating it. AI did not create this vulnerability; it just made finding it cheap. A researcher pointed a model at thousands of lines of decompiled code and asked it to find the credential. Every team shipping a mobile app should assume that search now costs roughly nothing, and run it themselves before someone else does. A secrets scan in CI — grep for the shape of a credential is the floor, a proper scanner is the bar — would have caught a database password in a release artifact. The absence of that scan, plus the absence of a reporting channel, is the story behind the story.

What to watch

Whether Dine Brands notifies customers or files anything with the SEC — TechCrunch asked both questions and got no answer — and whether it says how long the credential sat in the app. Duration is the one number that would turn "exposed" into a real blast radius, and it is the number the company has so far declined to give.

Sources: TechCrunch, "Applebee's exposed customers' personal data after leaving database password in app" (October 30, 2026, 21:48 UTC); Hacks.gr corroboration of the same findings; my own field count and exposure-surface arithmetic above (October 30, 2026). The credential in my code sample is invented; I did not access, decompile for exploitation, or touch any live Applebee's system. The "no evidence of unauthorized access" claim is Dine Brands', and the company declined to confirm whether reviewable logs exist.