Mobile

Applebee's Android app shipped its database password

By Yaali. November 2, 2026, 6 min read, Mobile, Identity, Threat intel.

A database password hardcoded in Applebee's Android app exposed customer names, birth dates and phone numbers. How it happened and how to check your own apps.

Applebee's Android app, which has more than a million downloads on Google Play, contained the password for an internal customer database. Anyone who downloaded the app could pull the password out of its code and log in to that database as an authorised user. UK researcher Robert Wiggins of What Security found it earlier in October, and TechCrunch confirmed it by decompiling the app and retrieving a test account it had created. Applebee's said on October 29 that it had acted to prevent unauthorised access, and TechCrunch published on October 30.

The records held names, email addresses, dates of birth, phone numbers, ZIP codes and veteran status, plus login counts and the IP address of each customer's last login. Nobody knows how many customers were reachable: Applebee's would not say, and Wiggins did not count rows. Its rewards programme had at least 8.5 million members last year. If you hold an Applebee's account, expect phishing that quotes your real birth date and phone number. If you ship a mobile app, this is a cheap mistake to check for today.

How it works

An Android app ships as an APK file, a zip archive holding compiled bytecode, resource files and bundled assets. Free decompilers such as jadx turn that bytecode back into readable Java-like source in seconds. Any string the developer compiled in, whether in a constants class, a generated BuildConfig file, res/values/strings.xml or a config file under assets/, comes out as plain text. Obfuscation tools rename classes and methods, but they leave string values readable unless the developer adds extra encryption, and the app has to decrypt them at runtime anyway.

The design flaw sits one step earlier. The app authenticated to the database with one shared credential, the same in every installed copy, instead of sending each user's own session token to a backend that checks what that user may see. Once a credential sits inside the client, the server can no longer tell the real app from someone running a script with the same password. MITRE catalogues this as CWE-798, use of hard-coded credentials, and it sits at the top of the OWASP Mobile Top 10 for 2024 as M1, improper credential usage.

Applebee's has not said which database platform it used, how the app connected, or what permissions the credential held. Wiggins said it could also have allowed changes to customer records; that was not tested and is unconfirmed. Wiggins used an AI model to search thousands of lines of decompiled code for the secret, which matters because it shows how little effort this takes now. Anyone can do the same search on any public app.

What we know about access

There is no public evidence that anyone used the password before Wiggins. A Dine Brands spokesperson said its security team "has not currently found any evidence of unauthorized access" and that the investigation is ongoing. The company would not say whether its servers keep logs that could show who connected, how long the password had been in the app, or whether it will notify customers, regulators or the SEC.

A claim of no evidence is only as good as the logging behind it, and the company has declined to say whether that logging exists. The disclosure itself was also slow by design: neither Applebee's nor Dine Brands offered a way to report security issues, so Wiggins asked TechCrunch to pass the report on. TechCrunch held its story until the fix was confirmed.

For customers, the fields involved are the ones used to verify identity over the phone. A birth date, phone number and ZIP code together are enough to make a call to a bank or mobile carrier sound convincing, and none of them can be changed like a password can.

What to do

If you hold an Applebee's account, watch for calls and texts that cite your details and push you to act fast, and add a carrier account PIN to stop SIM swap requests made with your birth date. There is nothing to reset on the Applebee's side, because no passwords were reported in the exposed fields.

If you ship a mobile app, work through these in order.

1. Scan what you actually shipped. Download your production APK from Google Play, or pull it from a test device with adb shell pm path <package> and adb pull, then run jadx -d out app.apk. Run a secret scanner such as gitleaks dir out or trufflehog filesystem out over the result, and also search by hand for jdbc:, mongodb://, postgres://, password and long base64 strings. Scanning the repository is not enough, because build pipelines often inject secrets that never appear in source control.
2. Revoke on the server, not only in the build. Removing the password from the next release fixes nothing on its own: old APKs stay on phones and on mirror sites for years. Change or disable the database user, then confirm the old credential is refused.
3. Put an API between the app and the data. The app should hold only a short-lived token tied to the signed-in user. The backend checks that token and returns that user's record and nothing else. Database ports should not be reachable from the internet at all.
4. Scope whatever must stay in the client. Some keys have to ship, such as a maps API key or a Firebase project config. Restrict each one to your app's package name and signing certificate, give it the narrowest permissions the vendor allows, and make sure database security rules enforce per-user access instead of trusting the key.
5. Check whether someone got there first. Pull connection and authentication logs for the exposed database user and list source IP addresses. Traffic from your own backend hosts is expected; logins from residential or hosting provider ranges, or bulk reads outside normal app patterns, are not. If you have no such logs, say so in your incident record and treat the data as exposed for notification purposes.
6. Publish a way to reach you. Add a /.well-known/security.txt file (defined in RFC 9116) with a reporting contact, and link a short disclosure policy. Without one, researchers like Wiggins have to route reports through journalists.

Treat the client as public

Everything inside a mobile app, a desktop app or a single-page web app should be treated as published. Shipping it to a million phones is the same as posting it online. The useful test for any secret in a client is to ask what happens if a stranger copies it and calls your backend with it. If the answer is "they can read other customers' records", the secret is doing a job that belongs to server-side authorisation.

Add the decompile and scan step to your release checklist, run it on the signed build that goes to the store, and fail the release if it finds a live credential.

Our mobile penetration testing team decompiles release builds and tests whether embedded keys reach customer data, and our red team code review traces how the app authenticates to its backend. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: TechCrunch, International Business Times Singapore, Secure Blink, OWASP Mobile Top 10 2024, M1, MITRE CWE-798, RFC 9116.