BK Japan, which runs the Burger King chain in Japan, said on October 15, 2026 that an unauthorized third party got into the system that manages members of its official smartphone app. About 11.18 million member records were exposed. Every source we reviewed (Kyodo, EFE via Infobae, TBS via News On Japan, and Blocktempo) gives the same figure. The company says it has seen no fraudulent use of the data so far and is still investigating with outside experts. This is one of the largest incidents in a run of breaches at Japanese consumer companies since September. Japan's national CERT, JPCERT/CC, has publicly linked part of that run to attacks on backend APIs found by taking apart mobile apps. However, no source has yet tied the BK Japan intrusion to a specific technique or actor.
What Happened
According to EFE, News On Japan (citing TBS) and Blocktempo (citing Japanese media), the unauthorized access ran from October 2 to October 7, 2026. Blocktempo reports that BK Japan confirmed the leak on October 13, two days before it went public. Kyodo describes the target as "a server managing data from its official smartphone app." Other outlets call it the app's member management system.
BK Japan's statement, as quoted by EFE, blames "unauthorized access by a third party." It says the company is investigating with outside organizations and will strengthen system security and monitoring. Blocktempo reports that affected members are being notified by email. The company apologised for "the significant inconvenience and concern" the incident caused (TBS, via News On Japan).
The root cause has not been disclosed. No group has claimed the attack, and no source names a threat actor.
What Was Taken
Every source puts the total at about 11.18 million records. None of them says whether that means 11.18 million unique people, so de-duplicated individuals could be fewer.
The sources list different data fields, probably because each one summarised the company's notice differently:
- Kyodo: names, dates of birth, email addresses, phone numbers, gender
- Blocktempo: 10 fields in total, including member ID, email, name, phone number, date of birth, gender and prefecture of residence
- EFE: email address, place of residence and phone number, "among others"
- TBS / News On Japan: names, phone numbers and email addresses
Taken together, the likely set is member ID, full name, date of birth, gender, email, phone number and prefecture. Blocktempo's 10-field count is the most detailed account, but it is still secondhand.
Not affected, per the company: BK Japan says it does not store credit card numbers (Kyodo, EFE, TBS). The sources word the password position differently. TBS reports that passwords were not included. EFE and Blocktempo say only that no password leak has been confirmed so far. Treat "no passwords exposed" as provisional until the investigation is finished.
This data is not financial, but it is very useful for social engineering. Name, date of birth, phone and email together are enough to build convincing phishing and impersonation attempts. EFE reports that BK Japan has already warned customers about emails and calls pretending to come from the company.
Why It Matters
Scale and timing. BK Japan is the latest of several Japanese consumer brands to report app member breaches in a few weeks. Blocktempo and other sources list these:
- Yakiniku King: about 10.79 million app members, roughly 99.8% of its registered base
- BOOKOFF: about 6.43 million records
- Times Car: about 6.6 million accounts
- Ride On Express (Gin no Sara): up to 6.5 million records, possibly exposed
- The SpeeCAN RAIDEN disaster alert system used by local governments
RUNSERVER, a Japanese engineering blog, estimates the combined total from the wave at 60 to 100 million records. Blocktempo points out that these figures can't simply be added up, because the companies count differently and many people are members of more than one service.
Possible common pattern, not confirmed for BK Japan. JPCERT/CC issued a warning on October 8 and updated it on October 9, as summarised by Japan Cyber Watch. It describes four attack patterns behind the wave:
- scanning for known vulnerabilities and exposed files
- abuse of internal APIs found by analysing public smartphone apps
- exploitation of a Metabase SQL injection flaw
- web shells hidden in WAR files on Java application servers
BK Japan's breach involved an app member system, which matches the profile of the second pattern. But no source we reviewed says JPCERT/CC or BK Japan has linked this incident to the wider campaign. Read it as a plausible connection that hasn't been established.
The AI question. EFE says media and experts "consider it likely" that attackers used AI agents across the wave, while noting this is unconfirmed. JPCERT/CC's October 15 blog post says it saw attackers using AI for vulnerability scanning and API attacks on the attacker servers it examined. That post does not name BK Japan. In a Yahoo! News expert piece, Ikeda Tomoko's review of four earlier victims' disclosures found no mention of attackers using AI. Japan Cyber Watch also reports that a Macnica analysis of 119 web breaches found no sign of AI-discovered zero-days. AI-assisted reconnaissance looks real across the campaign, but there is no evidence that it caused this specific breach.
The Attack Technique
BK Japan has not disclosed how the attackers got in. The most relevant context is what investigators have found about the broader wave:
- Taking apart the app to reach the API. JPCERT/CC's October 15 post describes attacker servers holding Android APK files, along with jadx and Blutter, a tool for reverse-engineering Flutter/Dart apps. The attackers used these to pull out backend API endpoints and then probe them for flaws such as SSRF. One server held a Python script that returned HTTP 302 redirects, consistent with testing for SSRF. JPCERT/CC cites a NICT advisory from October 13 that names "server attacks via app analysis" as one cause of the breaches. The infrastructure also targeted apps built for markets outside Japan.
- Authorization failures, not old frameworks. RUNSERVER argues that the core problem in these app breaches is broken object-level authorization: APIs that check that a caller is logged in but not whether they are allowed to see a given record. That lets an attacker pull down the whole member table. This is the outlet's own analysis, not a finding about BK Japan.
- Signs of a wider toolkit. On a separate server that JPCERT/CC says is not directly linked to these attacks, it found tooling aimed at MySQL, Jenkins and mail gateways, plus traces of EDR bypass attempts and web shells.
The one firm fact about BK Japan is that the intrusion lasted about six days, from October 2 to 7, and pulled data from the app member store. That pattern looks like bulk extraction over time, not a single quick grab. It suggests that rate limits or anomaly detection on the member API either did not exist or did not trigger.
What Organizations Should Do
- Assume your mobile app is fully mapped. Anyone can decompile APK and IPA files. List every backend endpoint your app calls, including undocumented and legacy ones, and test each as though the attacker has the source code.
- Enforce authorization on every object, on every request. Being logged in is not enough. Each member record request must check that the requester owns that record. Test specifically for IDOR and BOLA by changing IDs in requests.
- Rate-limit and alert on bulk reads. JPCERT/CC's guidance puts API rate limits first. Six days of steady extraction should trip a volume or enumeration alert. Baseline normal per-token and per-IP read volumes, and alert on large deviations.
- Use short-lived, tightly scoped tokens. JPCERT/CC recommends short token lifetimes. Don't embed long-lived keys or credentials in app binaries.
- Hunt using the published indicators. Check web and API logs against the attacker IP addresses and User-Agent strings JPCERT/CC released on October 8 and 9. Scan Java application servers for unexpected WAR files and web shells, and patch exposed Metabase instances.
- Collect and keep less data, and prepare for phishing. Delete data from closed accounts (BOOKOFF's breach included more than 210,000 former members). Warn customers early about impersonation, because exposed name, date of birth and phone data will fuel targeted scams.
Sources: Burger King's Japan operator says 11.18 mil. customer records exposed | 連続不正アクセス事案の攻撃手法に関する調査 - JPCERT/CC Eyes JPCERTコーディネーションセンター公式ブログ | 【2026年秋の異常事態】「アプリから流出」のウソと真実。焼肉きんぐ・タイムズカー・IDCFクラウド等から読み解く「4大侵入パターン」... | JPCERT/CC Warning on Japan's Breach Wave: API Abuse, Web Shells and... | 日本個資外洩接連爆：漢堡王、燒肉 King 各外流逾千萬筆個資 動區動趨-最具影響力的區塊鏈新聞媒體 | なぜデータ漏えいが頻発？AIエージェントのせい？ 焼肉きんぐなど4社の公表を読む（いけとも） - エキスパート - Yahoo!ニュース | Burger King en Japón alerta de la filtración de 11 millones de dato... | Burger King Reports Data Leak Affecting 11.18 Million Members News...