A UK-based researcher found a live database password inside Applebee’s Android app, then found the restaurant chain gave him no way to tell it. The fix only arrived after a journalist acted as go-between, and UK organisations without a disclosure route should take note.
What happened
Robert Wiggins, a security researcher at What Security who is based in the UK, discovered in October that Applebee’s Android app contained a hardcoded credential for an internal customer database. Its Google Play listing shows over a million installs. Wiggins says he used AI to search the app’s decompiled code, which runs to thousands of lines, and the credential gave access to records belonging to the chain’s registered customers.
His next problem was not technical. Applebee’s and its owner, Dine Brands, offered no published way to report a security issue. No security contact, no disclosure policy, no bug bounty. Wiggins turned to TechCrunch, which checked the claim independently by decompiling the app and creating an account populated with dummy data, then watching Wiggins pull that test record back out of the database. The publication held its story until Applebee’s confirmed a fix on Thursday 29 October, and published on 30 October.
A Dine Brands spokesperson, who was not named, said the company’s security team had opened an investigation and had so far found no evidence of unauthorised access. It would not confirm whether logs exist that might reveal earlier access, how long the credential had been in the app, how many customers were affected, or whether it would notify customers or regulators. TechCrunch put the chain’s rewards membership last year at no fewer than 8.5 million.
The technical picture
Hardcoding a credential in client software is one of the oldest mistakes in application security, and one of the most damaging. A mobile app is a package that anyone can download, unpack and read. Whatever secret ships inside it is, in practice, published. Anyone who extracts the password can talk to the back-end system exactly as the app does, with whatever rights that account holds.
In this case the reported data set included customer names, email addresses and whether each was verified, dates of birth, phone numbers, ZIP codes, veteran status, how many times each account had been logged into and when it was created, plus the IP addresses behind recent logins. Those last entries can reveal approximate location. No payment card data was reported. Wiggins also said the credential could have let an attacker change customer records, not just read them, although the independent verification covered read access.
Two details reflect well on the research. Wiggins deliberately did not count the records, because doing so would have meant touching potentially every customer’s data. And the AI element matters: it shows that combing through decompiled code for secrets, once tedious, is now cheap and fast for anyone, well meaning or otherwise.
Why it matters for UK organisations
Applebee’s is an American business, but the disclosure gap at the heart of this story is common on this side of the Atlantic too. Plenty of UK retailers, hospitality groups, councils and app publishers have no published reporting route. Researchers are left guessing: a customer service inbox, a social media message, or a journalist.
For some UK businesses this is no longer just good practice. Under the Product Security and Telecommunications Infrastructure (PSTI) regime, manufacturers of consumer connectable products sold in the UK must publish information on how to report security issues, with expected timescales for acknowledgement and status updates. That information must be free, in English and available without anyone having to ask.
The legal backdrop makes the gap worse for UK researchers. The Computer Misuse Act 1990 still offers no defence for good-faith security research. The government has promised a statutory defence, but reporting by The Record earlier this year suggested the planned protection would be narrow and tied to accreditation that few practitioners hold. A researcher who finds a live credential and cannot reach the owner is in an awkward position: every extra step to prove the issue or find a contact raises their own legal exposure. A clear disclosure policy with safe harbour language removes much of that friction.
Expert view
In my experience, the organisations with the worst disclosure handling are rarely hostile. They simply never planned for a stranger emailing to say their production database is open. The report lands in a general inbox, is mistaken for spam or a sales pitch, and goes nowhere.
When we test mobile apps, secrets in the client turn up more often than they should: API keys, cloud storage tokens, occasionally full database credentials. The fix is architectural. The app should authenticate users to a back-end service that enforces authorisation on the server, and it should never carry a credential that grants direct database access. Build pipelines should scan for secrets before release, and any credential that has ever shipped must be treated as burned and rotated, not merely removed from the next version.
The company’s statement also deserves scrutiny. Saying no evidence of unauthorised access has been found means little if you cannot confirm what logging exists. For a UK controller, that question would matter a great deal when deciding whether a personal data breach is reportable to the ICO within 72 hours. “We have no logs” is not the same as “nothing happened”.
The researcher’s restraint also deserves credit: no bulk enumeration, a test account for proof and a reputable intermediary when the front door was missing.
What to do now
- Publish a reporting route this week. Put a security.txt file (RFC 9116) at /.well-known/security.txt on your main domains, naming a monitored contact and linking to your policy.
- Write a short vulnerability disclosure policy. Say what is in scope, how quickly you will acknowledge reports, how you will keep researchers updated, and that you will not take legal action against good-faith reporters. The GOV.UK reporting page is a useful model.
- Keep a direct channel even if you use a bounty platform. Some researchers will not accept platform terms, so a plain email route should remain open.
- Audit your apps for embedded secrets. Decompile your own mobile releases, run secret scanning in CI, and rotate anything found. This maps to Cyber Essentials secure configuration and user access control.
- Check your logging. Make sure database and API access logs exist, are retained and can answer the question “who accessed this, and when?” before a researcher or regulator asks it.
- Rehearse the process. Send a test report at an awkward hour and see whether it reaches someone with the authority to act.
Bottom line
The vulnerability was basic and the fix, once someone was listening, came quickly. The real failure was that a careful researcher had no way to be heard. A disclosure policy and a security.txt file cost almost nothing to set up. Without them, your security response depends on a stranger’s patience and a journalist’s goodwill, and UK organisations should not leave it to chance.
Sources
- TechCrunch: Applebee’s exposed customers’ personal data after leaving database password in app
- IBTimes Singapore: Applebee’s customer data exposed after database password was hardcoded in Android app
- Secure Blink: Applebee’s hardcoded database password exposed customer data
- DEV Community: Applebee’s shipped its database password inside its app
- Pen Test Partners: UK PSTI? You’ll need a vulnerability disclosure program
- The Record: UK plans for cybercrime law reform would protect almost no one, experts warn
