Technology

Applebee's Fixes Flaw That Exposed Customer Data Through Password in Android App

Martin HollowayPublished 2w ago4 min readBased on 1 source
Reading level
Applebee's Fixes Flaw That Exposed Customer Data Through Password in Android App
Photo by Mjs92984 / CC BY-SA 4.0

Applebee's has fixed a security flaw that allowed anyone to access the personal information of its registered customers, according to a TechCrunch report published on October 30, 2026. The exposure stemmed from a password for an internal customer database that had been left inside the company's mobile app.

U.K.-based cybersecurity researcher Robert Wiggins of What Security discovered the lapse in October 2026. He used AI to locate the credential, which was buried in thousands of lines of source code in Applebee's Android app. That app has more than one million downloads on Google Play. The hardcoded credential allowed access to the customer database and could also have allowed modification of customer data.

TechCrunch verified the findings by downloading and decompiling the Android app and confirming that it contained the exposed credential. It then created an Applebee's account populated with dummy data, which Wiggins retrieved from the company's database.

The exposed database contained customer names, email addresses, email verification status, dates of birth, phone numbers and ZIP codes. It also held veteran status, login counts, account creation dates and the IP addresses of most recent log-ins. Applebee's had at least 8.5 million customers enrolled in its rewards program as of 2025.

Wiggins could not alert Applebee's or its parent company, Dine Brands, directly, because neither offered a way to report security issues. TechCrunch withheld publication of its story until the bug was confirmed to be fixed.

Dine Brands said its security team promptly investigated the Applebee's issue and had not currently found evidence of unauthorized access. The company declined to say whether it has server logs that would show whether anyone accessed the database.

In my view, the technical root cause is an old one. A secret compiled into a client binary is effectively public, because anything shipped to a device can be decompiled and read. The credential did not need to be sophisticated to be exposed, only to exist in the wrong place. What changed is the cost of finding it. Locating a single string in a large codebase used to take persistence and luck. Using AI to search decompiled or source code compresses that work considerably, which means a secret that sits in an app for months is now far more likely to be found by someone outside the company.

The broader context here is the disclosure gap. An app with more than a million downloads, tied to a rewards program of millions of members, gave an outside researcher no route to report a critical finding. Wiggins's account suggests the first person to notice a problem had little option other than going public or going nowhere. Organizations that publish a security contact or a vulnerability disclosure policy give researchers a channel that does not depend on a news outlet. That channel is cheap to set up, and it is the piece most often missing when a flaw like this surfaces.

The same tooling that made this credential easy to find can also be turned around. Secret scanning in continuous integration, run before a build ships, catches hardcoded credentials at the point where they are cheapest to remove. The fix came only after an outside party found the problem, and the people whose names, dates of birth and log-in IP addresses sat in that database had no part in the discovery.