Threat intel

BK Japan, which runs Burger King in Japan, said on October 15 that a third party got into the system that manages member information for its official smartphone app. The company counts about 11.18 million member records as leaked. The unauthorised access ran from October 2 to October 7, and the company confirmed the leak on October 13, six days after the access ended.

The figure counts records, not confirmed people: one person can hold more than one account, and some accounts are long dormant. Card numbers were not on the affected system, because the company does not keep them, and it says it has found no evidence that login passwords leaked. It has not said how the intruder got in. If you hold a Burger King Japan app account, assume your name, email address, phone number and date of birth are in the set. If you run a consumer app or loyalty programme of your own, the useful part is the questions this case raises about your member database.

What leaked, field by field

According to BK Japan's notice, as reported by INTERNET Watch, ITmedia, CyberInsider and Hackread, each record can include:

• member ID
• email address
• name, which Japanese sources say covers both the kanji and the kana (phonetic) spelling
• phone number
• date of birth and gender
• prefecture of residence
• registration type
• whether the member has used mobile ordering

That last field needs care. Some English-language reports, including BleepingComputer, describe it as "order history". The Japanese notice, and CyberInsider's reading of it, list only whether a mobile order history exists, as a yes or no flag, not the items, amounts or dates of past orders. Until BK Japan says otherwise, treat it as a flag.

The company says it blocked traffic from the source of the access as soon as it found it, reported the incident to Japan's Personal Information Protection Commission (PPC), the national privacy regulator, and is investigating with outside specialists. It says it has seen no misuse of the data so far.

How the data gets used

A record that ties a verified name to a working phone number, an email address and a date of birth is a ready-made phishing target. The mobile-ordering flag adds one more thing: it tells a fraudster which people actually use the app, and so are most likely to believe a message about it.

The likely follow-ups come by text, email and phone:

1. SMS phishing (smishing): a text that uses your real name and claims a problem with a mobile order, a coupon about to expire or a points refund, with a link to a fake login page. BK Japan has warned members about fake emails, texts and calls, and Japanese coverage points out that the leaked fields are enough to write a message addressed to the right person at the right number.
2. Email phishing: the same lure, sent to the leaked address. A message that quotes your date of birth and prefecture back to you looks like it came from someone who already knows you.
3. Voice phishing (vishing): a caller claims to be from the app's support team, reads out your name and birthday to sound genuine, then asks for the one-time code that has just arrived on your phone. That code can hand the caller your account at any service that sends sign-in codes by SMS.

Because the company never stored card numbers, any message that says your card was exposed in this incident is false, and is itself a sign of phishing.

Dates of birth also outlive the incident. People cannot change them, and some banks, mobile carriers and older services still use them as a recovery question or as part of a phone identity check.

What customers and IT teams should watch for

For app members:

• Open the official app or type the website address yourself to check any notice about orders, coupons or your account. Do not follow links in texts or emails that mention this breach.
• Never read a one-time code to a caller. No legitimate support desk needs it.
• If you reused your Burger King app password elsewhere, change it on those services. Passwords are not confirmed as leaked, but the investigation is not finished.
• Where your mobile carrier or bank offers a port-out PIN or verbal password, set one. A name, phone number and birth date cover much of what a phone identity check asks for.

For IT and security teams with staff in Japan, the leaked emails may include work addresses, if staff signed up with them. Add lures that mention Burger King, mobile orders or coupon refunds to your phishing awareness notes this month, and watch mail gateway reports for messages that reuse those themes.

What app owners should check

BK Japan has not disclosed the entry point, so there is no specific flaw to patch here. What the case does show is a member database read at scale over six days, with the leak confirmed six days after the access stopped. Any team running a consumer app can test its own setup against that.

Member-management API authorisation. Most consumer apps talk to a backend API that returns member profiles. Check that every endpoint returning a profile takes the member ID from the authenticated session, never from a request parameter the client controls. If changing memberId=1001 to 1002 in a request returns someone else's profile, any logged-in user can walk the whole table. This flaw is called broken object-level authorisation (BOLA), and it ranks first in the OWASP API Security Top 10. Admin and support endpoints that can search or list members need the same review, plus a separate login with phishing-resistant multi-factor authentication (MFA).

Rate limits and result caps. A single app user has no reason to fetch thousands of profiles an hour. Set per-token and per-IP limits on profile and search endpoints, and cap page sizes on any list call, so a stolen token cannot page through millions of rows in one session.

Bulk-export detection. Alert when any account, token or service identity reads far more member rows than its normal daily volume, and on large responses or long-running full-table queries against the member store. Include reporting, analytics and customer-support tools, which often have the widest read access and the least monitoring.

Log retention. BK Japan could date the access to October 2 through 7 because it had records covering that window. Keep API gateway, database audit and identity provider logs for at least 90 days in storage the application's own admins cannot delete, so an investigation can still answer what was read, by whom and from where.

Data you hold but do not need. Ask whether every app member needs a full date of birth on file, or whether a birth month for promotions would do. Accounts that have not logged in for years can be closed on a schedule, which shrinks the record count a single intrusion can reach.

Our mobile penetration testing work tests app backends for exactly these authorisation and rate-limit gaps, and our security operations team watches for bulk reads like the one in this case. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: BleepingComputer, Cybernews, Security Affairs, HotHardware, CyberInsider, Hackread, INTERNET Watch, ITmedia Mobile.