Burger King Japan app breach: about 11.18 million member records, and a risk score for what the company exposes online.

Six days of access, found six days later. From Friday 2 October to Wednesday 7 October 2026, a third party had access to the system that manages members of the official Burger King app in Japan. On Tuesday 13 October the operator, BK Japan, established that about 11.18 million member records had leaked, and it disclosed this on 15 October. Names, email addresses, phone numbers and dates of birth are in them. It is the second restaurant-chain app in ten days to lose about 11 million records, after Yakiniku King.

At a glance. Original graphic for this article.

Below: what BK Japan has said, what its dates show, and a risk card that scores the company's internet-facing systems from passive records, without publishing the details an attacker could use.

What BK Japan has disclosed

BK Japan (株式会社ビーケー・ジャパン) runs Burger King restaurants in Japan and the official app. It published its notice as a PDF on 15 October 2026. BK Japan notice (Japanese, PDF)

2 October (Fri) to 7 October (Wed). A third party accessed the system that manages official-app member information.
13 October (Tue). After investigating the possibility of unauthorized access, BK Japan established that member information had leaked. It says it blocked communication from the source immediately after it learned of the access.
15 October. BK Japan published the notice. It has reported to the Personal Information Protection Commission, set up a task force and put interim measures in place. Permanent measures, an investigation with outside specialists and emails to affected customers are under way. ITmedia Mobile (Japanese) · INTERNET Watch (Japanese)

What	Detail
Records	About 11.18 million official-app member records (約1,118万件). The notice gives no exact count
Data that leaked	Member ID, email address, registration type, prefecture, gender, date of birth, name in kanji and kana, phone number, whether the member has used mobile ordering, whether the email address was verified
Not included	Card numbers, which BK Japan says it does not hold
Passwords	“A leak of login password information has not been confirmed at present”
Cause	Unauthorized access by a third party; how it became possible is under investigation with outside specialists
Harm seen so far	No secondary harm, such as fraudulent use, confirmed

The same count and fields appear in every report we checked. GAME Watch (Japanese) · Cybersecurity.com (Japanese) · ITmedia Business (Japanese)

What the dates and fields say

Six days, then six more. The access ran for six calendar days, and the leak was confirmed six days after it ended. The notice does not say when BK Japan first suspected anything or when it blocked the source. If the block came on 7 October, BK Japan spent six days working out what had been taken, which is normal for an investigation. If it came later, the access stopped for some other reason. Either way, the public notice came eight days after the access ended.

“Not confirmed” is not “not leaked”. BK Japan says a leak of login passwords “has not been confirmed at present”. Yakiniku King's notice, by contrast, said passwords were not among the leaked data (our analysis). Until BK Japan says whether passwords were stored in the system that was accessed, and how, treat the app password as possibly known.

The fields that verify a person. Name, phone number and date of birth together are what many call centres use to confirm who is calling. Gender and prefecture make a fake message more personal. “Mobile order history yes/no” tells an attacker who actually orders through the app, and so who will expect an order or refund message. The notice does not define “registration type”.

About 11.18 million is a count of records, not people. One person can have more than one account, and some accounts are old. Nobody who has ever registered for the app should assume they are outside it.

The second restaurant app in ten days

On 5 October, Monogatari Corporation disclosed that 10,788,963 Yakiniku King app records had leaked after unauthorized access to its membership system. It confirmed that access on 2 October, the day BK Japan's began. Monogatari (Japanese)

The fields differ. Yakiniku King's leak had member numbers, names, emails and phone numbers, and the company said dates of birth, gender and passwords were not included. BK Japan's includes date of birth and gender. Neither company has named a cause or an app vendor, and nothing public links the two incidents.

On 13 October, the day BK Japan confirmed its leak, Japan's National Institute of Information and Communications Technology (NICT) warned of “A2B” attacks: study a company's public app, then attack the servers behind it (our analysis). NICT has not linked any company's breach to that pattern, and BK Japan has not said its app or API was the route.

Risk card: Burger King Japan from the outside

The risk card answers one question: what does BK Japan's internet-facing estate look like to someone who only reads public records? It does not explain the breach, and it is not a vulnerability assessment.

How we built it. Everything comes from records that already exist. We sent nothing to BK Japan's systems except the download of its notice:

certificate transparency logs, for names under burgerking.co.jp and the servers presenting its certificates;
existing records from a commercial internet-scanning service, collected by that service before 17 October;
public DNS records for the domain's mail authentication;
CISA's Known Exploited Vulnerabilities catalog;
two public trackers of ransomware leak sites, ransomware.live and RansomLook.

We fixed the categories, weights and rating rules before rating anything. Hostnames, addresses, ports and product names are left out on purpose: they help an attacker more than a reader. We report a live exposure at a named company to JPCERT/CC rather than publishing it.

Figure 1. Outside-in risk card for Burger King Japan, 17 October 2026. Original graphic for this article.

Category	Weight	Rating (0–3)	What we saw
Exposed sign-in and admin services	25	2, moderate	A sign-in page for a business application, not the customer app, is reachable from the internet. No databases, file sharing or remote-administration services were seen
Known-exploited flaws	20	0, none seen	No software we could identify matches CISA's catalog. Entries inferred from version banners on one load-balancer address were not counted: none is in the catalog, and that address has also served other customers
Unsupported software	20	0, none seen	No end-of-life software identified
Email impersonation protection	15	3, weak	The DMARC policy is monitoring only (`p=none`) and asks for no reports. The SPF record is strict
Internet-facing size	10	1, small	About a dozen servers present the company's certificate, with one cloud provider
Ransomware leak-site claims	10	0, none found	No claim against BK Japan on either tracker on 17 October
Overall	100		35 out of 100: Medium

The arithmetic. Each category is rated 0 to 3, and the score is the sum of weight × rating ÷ 3: 25 × 2 ÷ 3 + 15 × 3 ÷ 3 + 10 × 1 ÷ 3 = 16.7 + 15 + 3.3 = 35. Bands: Low below 34, Medium 34 to 66, High above 66. Higher means more risk.

What it cannot see. Most of the servers are cloud load balancers, which show the balancer and not the software behind it. Whatever runs the app's member system is not visible from outside, so the card says nothing about it, and “none seen” means none visible. Scan records are snapshots and can be days old. A Low score would not mean a company is safe, and Medium does not mean it was careless.

What would change it. The email setting accounts for 15 of the 35 points. A DMARC policy of quarantine or reject, with aggregate reports, would bring the score to 20, which is Low. Anyone can check the record with dig +short TXT _dmarc.burgerking.co.jp.

Why the email rating matters here

BK Japan's notice asks customers to watch for suspicious mail, SMS and phone calls that pose as the company. That is the right warning: 11.18 million people's names, emails, phone numbers and dates of birth are exactly what a convincing fake needs.

DMARC is how a domain owner tells receiving mail servers what to do with mail that claims to come from its domain but fails authentication. On 17 October, burgerking.co.jp published v=DMARC1; p=none;. Under the standard, p=none means the domain owner requests no specific action. With no rua address, BK Japan also receives no reports of who is sending mail in its name. RFC 7489, DMARC

Large mail services run their own spoofing checks, so a forged message may still be caught. But BK Japan has not asked them to refuse one. p=none meets the minimum Gmail asks of bulk senders; it is a monitoring setting, normally used on the way to enforcement. Google: email sender guidelines DMARC does nothing against lookalike domains, so filtering on your side is needed either way.

The attacker's playbook

How a red team would use this data. A model mapped to MITRE ATT&CK, not a reconstruction of this attack.

Stage	What it could look like	ATT&CK
Study the app	Read the public app and its traffic for the member endpoints and how they identify the caller	T1594 Search Victim-Owned Websites
Reach the member system	Weak authorization, a stolen credential, or a flaw in the system behind the app	T1190 Exploit Public-Facing Application
Collect over days	Script the requests and collect records for six days	T1119 Automated Collection; T1213 Data from Information Repositories
Send in the brand's name	Mail with a burgerking.co.jp From address, relying on a monitoring-only policy, or from lookalike domains	T1656 Impersonation; T1583.001 Acquire Infrastructure: Domains
Personalised lures	Coupon, refund or “account check” mail and SMS that use the member's real name and birth date	T1566 Phishing; T1660 Phishing (Mobile)
Pass identity checks	Call a help desk with name, phone number and date of birth to reset an account or redirect a payment	T1598 Phishing for Information; T1656 Impersonation

The defender's playbook

Response guide: the API data exposure playbook covers investigating and recovering from data read out through an app or API. Linking it here does not mean that is what happened at BK Japan.

1. If your staff or customers use the Burger King app

Messages. Expect mail, SMS and calls about Burger King coupons, orders, refunds or account checks that use real names and birth dates. Open the app or the official website yourself rather than following a link. The notice gives BK Japan's customer service number as 0120-945-630, weekdays 10:00 to 17:00.
Passwords. A password leak has not been confirmed, but it has not been ruled out. Change the app password and any account where the same one was used, work accounts first.
Identity checks. In your own call centre and help desk, treat name, phone number and date of birth as known to attackers for these customers. Use a callback or a code sent to a registered device instead.

2. If you run mail filtering

Do not rely on the sender's policy. Make sure your own spoofing protection acts on mail from burgerking.co.jp that fails authentication, even though the domain asks for no action. Query 1 finds what has already reached your users.
Lures from other domains. Query 2 finds mail that names Burger King but comes from elsewhere. Block confirmed fakes, and add them to the next staff warning.

3. If you run a member app

Alert on volume per caller. A member system that returns records for six days should trip a volume alert on the first. Our SourceNext analysis has a query for a caller reading far more than its own baseline.
Return less. Ask whether the app needs to return date of birth at all once a member has signed up.
Decide in advance who can block a source, and how fast, so “immediately” has a time on it.
Enforce DMARC before you need it. Move to quarantine or reject, with reports, before you have to tell customers to watch for fake mail.

4. Which teams should act

Team	Scope	Next step	Evidence needed
Email Security	Mail claiming burgerking.co.jp, and mail naming Burger King from other domains	Run queries 1 and 2; block confirmed fakes; check spoofing policy	Query results, block records
SIEM / SOC	Mail and sign-in logs since 2 October	Schedule both queries; watch for help-desk resets for staff who use the app	Query schedule, findings
IT Operations	Your own member apps and mail domains	Per-caller volume alerts; DMARC at enforcement with reports	Configuration, DMARC reports
Legal / Privacy	Staff data and customer-facing processes	Decide whether to warn staff; review identity checks that rely on date of birth	Decision record
Third-party Risk	Vendors that build or host your apps	Ask which customers share the same app platform, and what monitoring it has	Written answers

Hunting

No indicators specific to BK Japan's incident have been published. These queries look for what follows: mail that claims to be from Burger King, in your own logs.

Both queries are illustrative and were not run against live data. Table and field names were checked against Microsoft's documentation on 17 October 2026 (JST). Both need Microsoft Defender for Office 365.

1. Mail with a burgerking.co.jp From address that did not pass DMARC. Microsoft Defender XDR advanced hunting.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting; needs Defender for Office 365.
// Inbound mail since 2 Oct 2026 whose visible From domain is Burger King Japan's but which did not pass DMARC.
// The domain's DMARC policy was p=none on 17 Oct 2026, so receiving servers are not asked to reject such mail.
// AuthenticationDetails holds verdicts such as {"SPF":"pass","DKIM":"pass","DMARC":"pass","CompAuth":"pass"};
// if DMARC comes back empty in your tenant, every message is kept, so check the column before trusting a quiet result.
let Since = datetime(2026-10-02T00:00:00Z);
let BrandDomain = @"(?i)(^|\.)burgerking\.co\.jp$";
let KnownForwarders = dynamic(["REPLACE_WITH_FORWARDING_RELAY_IP"]); // forwarding breaks SPF; list your own relays
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where SenderFromDomain matches regex BrandDomain
| where not(SenderIPv4 in (KnownForwarders))
| extend Auth = parse_json(AuthenticationDetails)
| extend DMARC = tostring(Auth.DMARC), SPF = tostring(Auth.SPF), DKIM = tostring(Auth.DKIM), CompAuth = tostring(Auth.CompAuth)
| where DMARC != "pass"
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by SenderFromAddress, SenderMailFromDomain, SenderIPv4, DMARC, SPF, DKIM, CompAuth, DeliveryAction
| order by Messages desc
| take 500

2. Mail that names Burger King but comes from another domain. Microsoft Defender XDR advanced hunting.

// Illustrative; not run against live data. Microsoft Defender XDR advanced hunting; needs Defender for Office 365.
// Inbound mail since 2 Oct 2026 that names Burger King or the Whopper but was not sent from its domain.
// BK Japan warns of fake mail, SMS and calls posing as the company. Expect news newsletters about the breach; list them as exceptions.
let Since = datetime(2026-10-02T00:00:00Z);
let LurePattern = @"(?i)burger\s*king|バーガーキング|whopper|ワッパー";
let OfficialDomains = @"(?i)(^|\.)(burgerking\.co\.jp|REPLACE_WITH_OTHER_VERIFIED_SENDER_DOMAIN)$";
EmailEvents
| where Timestamp > Since
| where EmailDirection == "Inbound"
| where Subject matches regex LurePattern or SenderDisplayName matches regex LurePattern
| where not(SenderFromDomain matches regex OfficialDomains)
| join kind=leftouter (
    EmailUrlInfo
    | where Timestamp > Since
    | project NetworkMessageId, UrlDomain
    ) on NetworkMessageId
| summarize Recipients = dcount(RecipientEmailAddress), UrlDomains = make_set(UrlDomain, 10),
    FirstSeen = min(Timestamp), LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| order by FirstSeen asc
| take 500

Downloads: spoofed-sender KQL · mail-lure KQL

No results is not proof that nothing arrived. SMS and phone calls, the other channels BK Japan warns about, do not show in mail logs. EmailEvents · EmailUrlInfo

Copy-paste template

Replace everything in [brackets]. Anything going outside the company should be checked by legal or privacy first.

Note to staff

Subject: Burger King app data leak – watch for fake messages that know your name and birthday

BK Japan, which runs Burger King in Japan, said on 15 October 2026 that about 11.18 million records of its official app's members leaked, including name, email address, phone number, date of birth, gender and prefecture. Card numbers were not held. A password leak has not been confirmed.
- Expect fake emails, texts and calls about Burger King coupons, orders, refunds or account checks. They may use your real name and date of birth.
- Do not use links or phone numbers in those messages. Open the Burger King app or official website yourself.
- If you have the app, change its password, and change it anywhere else you used the same one, starting with work accounts.
- Nobody from [Company] IT will ask for your password or a code because of this.
- Report suspicious messages to [report button or address].
Questions: [security contact].

What remains unknown

How the access happened: through the app's API, an administrative route, a stolen credential or a vendor.
When BK Japan first suspected it, and when it blocked the source.
Whether passwords were stored in the system that was accessed, and if so, how.
The exact number of records, and how many people they represent.
Who is behind it, and whether the data will be offered for sale.
Who built and hosts the app, and whether other companies share the same platform.

Sources and updates

17 October 2026: first published. We read BK Japan's notice directly from its website. We read the news reports through search results; we could not open those pages from our research environment. Every figure was checked against at least two sources. The risk card uses certificate logs and DNS records checked on 17 October (JST), and internet-scan records that service had already collected. We did not scan or log in to anything. Before publication, at about 21:00 JST, we re-checked the scan records for the sign-in page, the DMARC record and both leak-site trackers; none had changed.

30-second briefing