1. Executive summary
A database password embedded in Applebee's Android app gave researcher Robert Wiggins access to an internal Applebee's customer database holding names, email addresses, dates of birth, phone numbers, ZIP codes, veteran status, account-creation dates, login counts and the IP addresses of customers' most recent logins. TechCrunch independently verified the finding by creating an Applebee's account with dummy information and retrieving it from the database through Wiggins. Applebee's parent company Dine Brands confirmed on 29 October 2026 that the flaw was fixed, and says it has found no evidence of unauthorised access while its investigation continues. The number of affected records is not stated. No CVE has been assigned and no exploitation in the wild is reported, so the risk to EMEA financial services is indirect: the exposed fields are the raw material for targeted phishing and account-takeover pretexting against customers and staff who hold Applebee's accounts, and the case is a third-party data-handling exposure rather than a compromise of a financial institution.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item.
3. Technical analysis & attack chain
The exposure is a hardcoded credential: a database password written directly into the Android app's code or configuration. Anyone who extracts the password from the app package may be able to use it to reach the internal database. The source does not name the database engine, the host, the network path, the account's privileges, or whether the credential was still valid at the time of discovery.
Confirmed steps, as reported:
- A database password was present in the Applebee's Android app, embedded in its code or configuration.
- Wiggins extracted the password from the app, with help from AI, and used it to access an internal Applebee's customer database.
- The database returned customer records containing names, email addresses and email-verification status; dates of birth, phone numbers and ZIP codes; veteran status; account-creation dates and login counts; and IP addresses from customers' most recent logins.
- TechCrunch created an Applebee's account with dummy information, and Wiggins retrieved that record from the database, corroborating the access independently of the original discovery.
- Wiggins could not find a suitable route to report the issue to Applebee's or Dine Brands, so he asked TechCrunch to make contact. TechCrunch held publication until the fix was confirmed.
- Applebee's confirmed on 29 October 2026 that it had addressed the issue.
What the reporting does not establish: how many customer records the database held, how long the credential was present in the app, which app version or versions carried it, whether the credential was rotated as part of the fix or only removed from the client, and whether anyone other than Wiggins used it. Dine Brands says it has not found evidence of unauthorised access, and its investigation is ongoing. That statement is the company's own and is not a finding of no access.
The database fields described did not include payment card details or account passwords. The login IP addresses can indicate a customer's approximate location, which raises the value of the data for pretexting that references a plausible location. The source gives no technical detail on how the credential was stored (for example, whether it was obfuscated or encrypted in the package), so no assessment of extraction difficulty is possible from public reporting.
4. Mitigation & containment
The flaw is in a third-party consumer app, not in client infrastructure. The actions below address the exposure this item creates for clients and their customers. No fixed app version is named in public reporting, so version pinning cannot be specified.
P1 (within 24 hours)
- If the Applebee's Android app is installed on corporate-managed mobile devices, treat the embedded credential as compromised: remove the app from managed device policy or block it in the MDM catalogue until the vendor confirms the credential was rotated, not only removed from the client. The source confirms a fix on 29 October 2026 but does not state that the database password itself was changed.
- Add Applebee's and Dine Brands to the brand-impersonation watch list in the email and web gateway, and brief the service desk on refund, account-closure and payment-verification pretexts that reference the exposed fields (name, date of birth, ZIP code, veteran status).
P2 (within 72 hours)
- Where customers or staff are known to hold Applebee's accounts and the same email address is used for bank or payment access, run a targeted credential-reuse review. The exposed database did not contain account passwords, so this is a hygiene check on the email address as an identifier, not a password-compromise response.
- Ask any third party that processes customer loyalty or marketing data on the client's behalf whether it shares identifiers with restaurant or rewards programmes, and record the answer against the contract's data-handling terms.
P3 (within 7 days)
- Add a hardcoded-credential check to mobile app security testing for any consumer app the client publishes or distributes, covering secrets in code and configuration rather than only in network traffic.
- Update customer-awareness material to cover messages that quote a correct date of birth or ZIP code as a trust signal, since those fields were in the exposed database.
5. Indicators of compromise
No indicators of compromise available in the source material.
6. Detection
Insufficient indicators to author detection rules.
7. Sources
- Malwarebytes, "Applebee's customer data exposed by password left in app", https://www.malwarebytes.com/blog/news/2026/11/applebees-customer-data-exposed-by-password-left-in-app, 2026-11-02
8. Adverse Trace position
Adverse Trace assesses this as a low-severity item for EMEA financial services clients. The exposure is real and independently corroborated by TechCrunch's retrieval test, but the affected data set carries no payment card details and no account passwords, no CVE has been assigned, and no exploitation in the wild is reported; Dine Brands' statement that it has found no evidence of unauthorised access is single-sourced to the company and its investigation is ongoing. The residual client risk is targeted phishing built on accurate personal details, and third-party data-handling exposure where a client's customers or staff overlap with the Applebee's user base. We will monitor for a Dine Brands breach notification or a state regulator filing that states a record count or confirms access, and will reissue this advisory if either appears. Clients who need the app blocked on managed devices should raise it with their MDM owner today; the credential-rotation question in P1 is the one fact public reporting leaves open.
Published via PulseTrace — Adverse Trace threat intelligence.