On 30 October 2026, TechCrunch reported that Applebee's had exposed customers' personal data by leaving a database password hardcoded in its Android app, which has more than a million Google Play downloads. Security researcher Robert Wiggins of What Security found the credential, with help from AI tools, and it gave access to an internal customer database. According to TechCrunch, the exposed fields included names, email addresses and whether they were verified, dates of birth, phone numbers, ZIP codes, veteran status, login counts, account creation dates and the IP addresses of recent logins. TechCrunch verified the flaw with a test account and says the credential could also have allowed data to be changed. Applebee's confirmed the problem was fixed on 29 October. Its parent company, Dine Brands, says it has not found any evidence of unauthorised access and that its investigation is ongoing. The number of customers affected is not known.
Key takeaways
- According to TechCrunch, a database password hardcoded in Applebee's Android app gave access to an internal database of customer profile data.
- Exposed fields included names, emails, dates of birth, phone numbers, ZIP codes, veteran status and recent login IP addresses. TechCrunch did not list payment cards or account passwords among them.
- TechCrunch verified the issue by decompiling the app and creating a test account, and reports the credential could also have allowed data to be modified.
- Applebee's fixed the flaw on 29 October 2026. Dine Brands says it "has not currently found any evidence of unauthorized access"; no misuse is confirmed and the number of affected customers is unknown.
- The identity lesson: a database credential inside a mobile app is a shared machine identity handed to every user. It has to be removed from the app, not just rotated.
At a glance
| Organisation | Applebee's and its parent company Dine Brands, and Applebee's app customers |
|---|---|
| When | Exposure period not disclosed; fixed 29 October 2026; first public report 30 October 2026 |
| Attacker | None known. Found by security researcher Robert Wiggins of What Security, according to TechCrunch |
| Entry point | A database password hardcoded in Applebee's Android app, recoverable by decompiling the app |
| Identities abused | Exposed, not confirmed abused: the hardcoded database credential, which TechCrunch says allowed reading and modifying customer records |
| Impact | Customer profile data accessible to anyone holding the password; number of customers unknown; Dine Brands says no evidence of unauthorised access; no confirmed misuse |
| Category | NHI. Incident class: exposure, no confirmed misuse (hardcoded app credential found by a researcher) |
What happened
Applebee's runs a rewards programme through its mobile app; TechCrunch notes that the programme had at least 8.5 million members as of the previous year. According to TechCrunch, the Android version of the app contained a hardcoded password for an internal customer database. Robert Wiggins of What Security found it and said he used AI to help. Wiggins told TechCrunch that the credential could have allowed data to be modified as well as read. Malwarebytes reports that he could not find a proper way to report the issue, so he asked TechCrunch to help contact Applebee's and Dine Brands, and TechCrunch held its story until the fix was confirmed.
TechCrunch verified the issue by decompiling the app and creating a test account with fake details, which the researcher's method then extracted from the database. The exposed fields listed by TechCrunch are customer names, email addresses and whether they had been verified, dates of birth, phone numbers, ZIP codes, veteran status, number of logins, account creation dates and the IP addresses of the most recent logins, which can reveal approximate location. TechCrunch did not list payment card data or account passwords among the exposed fields, and did not say whether the database stored them. The article does not name where the database was hosted. Applebee's would not say how many people were affected.
Applebee's confirmed the flaw had been addressed on Thursday 29 October. In a statement to TechCrunch on Friday 30 October, Dine Brands said: "We appreciate TechCrunch and the security researcher for bringing this matter to our attention." It added: "Our security team promptly launched an investigation and has not currently found any evidence of unauthorized access," and "Our investigation is ongoing, and we will take appropriate steps based on our findings." Dine Brands has not said whether it has server logs that would show past access. TechRadar reported on 2 November that, as of its press time, Applebee's had not notified customers or published its own disclosure. We found no company statement on Dine Brands' own channels on 11 November 2026.
The same researcher later found a near-identical hardcoded credential in Wyndham's Android app, which TechCrunch reported on 9 November 2026; see our page on the Wyndham breach 2026. The two cases show how AI-assisted scanning of decompiled apps is making this class of flaw quicker to find.
Timeline
| Date | Event |
|---|---|
| October 2026 | Researcher Robert Wiggins finds a database password in Applebee's Android app and asks TechCrunch to help contact the company. |
| 29 October 2026 | Applebee's confirms the flaw has been fixed. |
| 30 October 2026 | TechCrunch publishes its report; Dine Brands says it has found no evidence of unauthorised access and that its investigation is ongoing. |
| 2 November 2026 | Malwarebytes and TechRadar report the exposure; TechRadar notes customers had not been notified as of its press time. |
| 9 November 2026 | TechCrunch reports a near-identical hardcoded credential at Wyndham, found by the same researcher. |
How it happened: the identity attack path
- A database credential ships in the app. The Android app contained a password for an internal customer database, according to TechCrunch, so every installed copy carried the same machine credential.
- The app is decompiled. The researcher, helped by AI tools, decompiled the app and found the password. TechCrunch repeated the process to verify it.
- The credential bypasses user-level checks. Using the password directly gave database access across customer records, rather than the single-account view a customer login would give.
- Read and write access. TechCrunch reports that the credential could have allowed data to be modified, not only read, which widens the potential for tampering.
- Fix, with history unknown. Applebee's fixed the issue on 29 October. Dine Brands has not said how long the password was in the app or whether its logs can show past access.
Impact
- Confirmed exposure (according to TechCrunch): names, emails and verification status, dates of birth, phone numbers, ZIP codes, veteran status, login counts, account creation dates and recent login IP addresses.
- Company position: Dine Brands says it has not currently found any evidence of unauthorised access and its investigation is ongoing.
- Not confirmed: any access beyond the researcher and TechCrunch, the number of customers affected and whether any records were changed.
- Not reported as exposed: payment card data and account passwords were not among the fields TechCrunch listed.
- Potential: targeted phishing and fraud using personal details, and tampering with customer records if the credential had been found by others. Malwarebytes advises customers to be wary of unexpected messages about Applebee's offering refunds or asking them to confirm payment details.
What this means for NHI governance
This is on an NHI list because the exposed secret was a machine credential. The database password belonged to a service, not a person, and it was distributed to everyone who installed the app. A hardcoded credential in a client app has no owner who can see who is using it, no meaningful scope per user and, until the app is changed, no way to rotate it without breaking every installed copy. It is a static secret with the widest possible audience.
The fix is architectural. Client apps should hold only the user's own short-lived session, and every request for data should pass through a backend API that checks that session and holds the database credential itself. Our Mobile App Security Guide and Secrets Management Guide explain the pattern, and the OWASP NHI Top 10 NHI2 Secret Leakage Guide sets it in the wider picture of leaked secrets.
The researcher's difficulty reporting the flaw is a second lesson. When there is no clear security contact, findings travel through journalists instead, which slows the fix. The same researcher's later finding at Wyndham, reported by TechCrunch on 9 November, shows the pattern is not unique to one company.
Recommendations
- Take database credentials out of client apps. Put a backend API between the app and the database, authenticate each user's session there, and keep service credentials on the server. See our Mobile App Security Guide.
- Scan release builds for secrets. Decompile and scan every app release, including older versions still installed, as part of the release process. See our Mobile App Security Testing Guide.
- Rotate and restrict after exposure. Revoke the exposed credential, rotate related secrets, and give any remaining service accounts the narrowest rights they need, with no write access where reads will do. See our Credential Rotation at Scale guide.
- Log service-account access to customer data. Keep access logs for database credentials long enough to answer whether an exposed secret was used. See our Database platform tokens leak response guide.
- Publish a vulnerability disclosure route. Give researchers a security contact and policy so issues reach you directly. See our Bug Bounty and Vulnerability Disclosure Guide.
Frequently asked questions
Was Applebee's hacked in 2026?
There is no confirmed hack. A researcher found a database password hardcoded in Applebee's Android app, and TechCrunch verified that it gave access to customer data. Applebee's fixed the flaw on 29 October 2026, and Dine Brands says it has not found any evidence of unauthorised access. Its investigation is ongoing, and it has not said whether its logs cover the whole exposure period.
What Applebee's customer data was exposed?
According to TechCrunch, the database held names, email addresses and their verification status, dates of birth, phone numbers, ZIP codes, veteran status, login counts, account creation dates and IP addresses of recent logins. Payment card data and account passwords were not among the fields TechCrunch listed. The number of affected customers is unknown.
What should Applebee's app users do?
Be cautious with unexpected emails, texts or calls about Applebee's, especially messages offering refunds, warning of account closure or asking you to confirm payment details, as Malwarebytes advises. Check any notice by opening the official app or website directly rather than following links. No customer notification had been reported as of TechRadar's 2 November report.
Related NHI Mgmt Group resources
Wyndham breach 2026 · Moltbook Database Exposure 2026 · Mobile App Security Guide · Secrets Management Guide · Leaked secret breaches
How NHI Mgmt Group can help
Hardcoded credentials persist because they are easy to add and nobody is tasked with finding them afterwards. NHI Mgmt Group helps organisations inventory machine credentials across code, apps and pipelines, move them into managed secrets with owners and rotation, and design client applications that never carry backend keys. See our NHI and AI agent security training.
References
- TechCrunch: Applebee's exposed customers' personal data after leaving database password in app (30 October 2026)
- Malwarebytes: Applebee's customer data exposed by password left in app (2 November 2026)
- TechRadar: Applebee's forced to fix serious security issue which exposed customer data (2 November 2026)