Burger King Japan Data Breach: 11.18M App Records, What to Know

BK Japan, which runs Burger King in Japan, says a third party accessed the member system behind its official app between 2 and 7 October 2026, exposing about 11.18 million member records: names, contact details, birth dates and order flags. The company does not hold card numbers. Members should expect convincing phishing and verify any message before acting.

Below: what is confirmed, what is still unknown, what members should watch for, what Japan's Act on the Protection of Personal Information (APPI) requires, and what consumer app teams can check this week. We do not speculate about how the intruders got in; the company has not said.

What happened

BK Japan (株式会社ビーケー・ジャパン) published a notice on its website on 15 October 2026. Impress Watch, ScanNetSecurity, BleepingComputer and Security Affairs all reported it, each working from that notice. The table follows their reporting. Dates are Japan Standard Time.

Confirmation came six days after the intrusion window closed, and the public notice two days after that. The reporting does not say when the activity was first detected.

What is still unknown

• How the intruders got in. No outlet reports an initial access method. Security Affairs says it has not been disclosed, and the company says it is investigating with external experts.
• Who did it. No threat actor has been named. None of the sources we read mention a ransomware group or a claim on a leak site.
• Whether the data has been published. The company says the information "leaked externally" (外部に漏えい), which in Japanese breach notices means it left the company's control. That is not the same as saying it has been posted or sold, and we found no report that it has been.
• How many distinct people are involved. The figure counts member records. Duplicate or dormant accounts are common, and the company has not broken the number down.

A separate notice in 2024

ScanNetSecurity reported that BK Japan announced a different incident on 22 October 2024, in which some customer information from the official app leaked after a cyberattack. That article gives no record count or field list. There is nothing in the 2026 reporting that links the two incidents, and we treat them as separate.

What data was involved

The field list below is from Impress Watch and ScanNetSecurity, both citing the company notice. Security Affairs lists the same fields. BleepingComputer summarises them as names, birth dates, gender, contact details and order history.

Two details matter. "Order history" in English coverage is, per the Japanese reports, a flag showing whether a member has used mobile ordering, not a list of orders. And "no leak confirmed" for passwords means the investigation has found no evidence yet, not that a leak is ruled out.

Who is affected

No misuse has been confirmed. If it comes, the likely form is social engineering, not card fraud.

What members should watch for

A name, birth date, phone number and email together make a message feel personal. The company has asked members to be wary of emails, SMS messages and phone calls that pretend to be Burger King services, and not to open links or attachments or enter member details or passwords through them. In practice:

1. Treat any "Burger King" message about this incident with care. Do not follow a link in an email or SMS to "check your account" or "claim compensation". Open the official app or type the address yourself.
2. Watch for messages that quote your birth date or prefecture. Those details now appear in the leaked set and will be used to sound legitimate. Knowing your birthday proves nothing about the sender.
3. Expect SMS phishing and calls. Phone numbers are in the data. A caller who knows your name and birth date is still a stranger; hang up and call back on a number you look up yourself.
4. Change reused passwords anyway. Passwords are not confirmed leaked, but if you used the same password for the Burger King app and elsewhere, changing the others costs little.
5. Review security questions on other accounts. If any service uses your date of birth as a recovery answer or PIN, change it.
6. Report phishing. In Japan, the Council of Anti-Phishing Japan accepts reports through a form on its website.

Japan's APPI reporting duties

Since 1 April 2022, Japan's APPI has made breach reporting and individual notification mandatory for private businesses when certain conditions are met. The PPC explains the rules on its leak response pages and in its general guidelines (通則編). This is a summary of those pages, not legal advice.

When a report is required

A business must report to the PPC, and notify the people affected, when a leak, loss or damage of personal data occurs, or may have occurred, and it falls into any one of four categories:

The scale and improper purpose categories each trigger the duty on their own. According to BleepingComputer and Security Affairs, BK Japan has reported to the PPC.

The guidelines also explain that "may have occurred" (おそれ) covers cases where there are traces of data being taken from a server holding personal data, infection by information stealing malware, traffic to known command and control servers, or a credible tip from a security company or public body. A team does not need certainty before the clock starts.

Deadlines

Most businesses use the PPC's online form. Where the PPC has delegated authority to a sector ministry, the report goes there instead.

What a report and a notice must contain

The report covers an overview with dates, the data items involved, the number of people, the cause, any secondary harm, how individuals are being handled, whether the incident is public, and prevention measures done and planned.

The notice to individuals is shorter: overview, data items, cause, secondary harm and other useful information. Post or email both work. Where people cannot be reached, the PPC accepts publishing the incident or opening an inquiry desk so people can check whether they are affected.

BK Japan's reported steps match those elements: a website notice, member emails, a PPC report and an outside investigation.

For teams outside Japan

If your app has users in Japan, ask counsel whether APPI applies to you; it can reach some businesses outside Japan. If it does, name who files the PPC report and who drafts the Japanese notice. The 3 to 5 day guide is shorter than many teams assume.

How app member data usually leaks

The company has not disclosed the cause, and nothing below is a claim about this incident. These are the common ways consumer app member databases leak, drawn from the OWASP API Security Top 10 (2023) and from the general pattern reported in Japan this year.

BleepingComputer quotes Macnica researcher Yutaka Sejiyama, who has logged 119 incidents this year in Japan involving theft or exposure of personal information. He describes attackers probing websites and APIs for access control and authentication weaknesses and exploiting known vulnerabilities. That matches what OWASP ranks highest for APIs:

Two other common routes are a vulnerable component in the backend (a framework, library or base image with a known CVE) and a compromised contractor account. That is why component inventory and vendor access reviews belong in the same plan as API testing.

What app teams can check this week

These steps are for teams that run their own member apps. Run them only against systems you own.

1. Find every table and column that holds member personal data. You cannot protect fields you have not listed. On PostgreSQL:

   SELECT table_schema, table_name, column_name
   FROM information_schema.columns
   WHERE column_name ILIKE ANY (ARRAY['%birth%','%phone%','%email%','%kana%','%name%','%address%'])
   ORDER BY 1, 2;
   

   For each field, ask whether the app still needs it. Birth date is often collected for a birthday coupon that only needs month and day.

2. Look for bulk reads in your access logs. A single client walking through member IDs leaves a shape you can see:

   grep -E 'GET /api/v[0-9]+/members/[0-9]+' access.log \
     | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
   

   Adjust the path to your own routes. A client with tens of thousands of distinct member lookups is worth a closer look.

3. Add a test that one member cannot read another member's record. This is the simplest check against object level authorization bugs, and it belongs in CI:

   def test_member_cannot_read_other_member(client, member_a_token, member_b_id):
       r = client.get(f"/api/v1/members/{member_b_id}",
                      headers={"Authorization": f"Bearer {member_a_token}"})
       assert r.status_code in (403, 404)
   

4. Rate limit member endpoints. For nginx, a basic limit looks like this:

   limit_req_zone $binary_remote_addr zone=members:10m rate=10r/s;
   location /api/v1/members/ {
       limit_req zone=members burst=20 nodelay;
       proxy_pass http://app;
   }
   

   Limit per authenticated user too, not only per IP address.

5. List every API host and version that can reach production data. Retire the ones nobody owns. Check DNS, load balancer rules and mobile app configs for old base URLs.

6. Inventory components in your backend and images. Know which services include which libraries and base images so a new CVE turns into a short list, not a search. With the Safeguard CLI:

   safeguard scan --dir .
   safeguard scan --image registry.example.com/member-api:prod
   safeguard scan --sbom ./sbom.cdx.json
   

   Results are written as JSON under ./output.

7. Publish DMARC so your notices can be trusted. After a breach, your real emails compete with fake ones. Check your record:

   dig +short TXT _dmarc.example.com
   

   A p=reject or p=quarantine policy with aligned SPF and DKIM makes direct spoofing harder. It does not stop lookalike domains, so tell members which domain your notices come from.

8. Rehearse the APPI timeline. Pick a date, pretend you learned of a leak that morning, and see whether you could file the preliminary report within 3 to 5 days with the fields the PPC asks for.

What would have helped

The cause is not public, so none of this is a judgement about BK Japan. It is what any consumer app team can put in place so that a breach is smaller, found sooner and handled faster.

Practices any team can use

• Collect less and keep less. A field you never stored cannot leak. Review the member schema every year and delete what no feature uses. Not holding card numbers, as BK Japan reports, is a good example of this working.
• Separate fields by sensitivity. Keep birth dates and phone numbers in a separate store or encrypted columns, readable only by the services that need them, so a bug in a profile endpoint does not expose everything.
• Test authorization, not only authentication. Every endpoint that takes an ID needs a test like the one above. Run it in CI on every change.
• Rate limit and alert on volume. Baseline how many member records a normal client reads per hour and alert above it. Multi-day bulk reads are what volume alerts are for.
• Know your components. Maintain an SBOM for each backend service and image so that when a framework or library CVE lands, you can find and rebuild affected services the same day.
• Review contractor access. Many app backends are built or operated by agencies. List who has production access, use separate accounts with MFA, and remove access when a contract ends.
• Prepare the notice before you need it. Draft the PPC report fields and a member notice in Japanese and English, and agree who signs off.

Zero-Day Discovery and Gold

Two Safeguard capabilities are relevant to the component part of the problem, with clear limits.

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in two modes, an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not look for authorization mistakes in your own API code, and there is no indication that a package flaw played any part in this incident. We make no claim that Zero-Day Discovery found or could have found anything related to it.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service with hardened drop-in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

The habit both support is simple: pull patched, signed components from a curated source, and rebuild and redeploy quickly when a fix lands. That shrinks the window in which a known bug in your backend stack can be used.

Where Safeguard fits

Safeguard helps with the component side of a consumer app backend:

• SBOM and dependency scanning of repositories, container images and SBOM files, plus a platform view of which projects contain a given component and version.
• Vulnerability matching against vulnerability databases, with reachability analysis to show which findings sit on code paths you use.
• Policies and gates evaluated in the platform, and autonomous remediation that opens fix PRs (off by default).
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict; safeguard exec runs it in CI. Desktop and phone apps can send work to a computer running the CLI and approve each command.

Where it does not help: Safeguard does not detect an intrusion in progress, block scraping, rate limit your API or prove that your authorization logic is correct. It does not send breach notices or file PPC reports. It does not stop phishing aimed at your members. Since the cause of this incident has not been disclosed, we cannot say whether any of the above would have changed the outcome, and we do not claim it would have prevented it.

Common mistakes and troubleshooting

• Treating "no passwords leaked" as "no risk". Names, birth dates and phone numbers are what phishing needs. Plan the member warning even when credentials are safe.
• Waiting for certainty before the PPC clock starts. The guidelines count a suspected leak (おそれ). The preliminary report can be filed with gaps and completed later.
• Rate limiting only by IP. Scrapes from rotating addresses get through. Add per account and per token limits.
• An SBOM for the app but not the image. Libraries in the base image count too. Scan the built image, not only the repository.
• Notices that look like phishing. A breach email with a shortened link and an unfamiliar sender domain trains members to click. Use your main domain, no link shorteners, and tell people to open the app themselves.

FAQ

What happened at Burger King Japan?

BK Japan says a third party accessed the system holding official app member information between 2 and 7 October 2026. It confirmed the leak on 13 October and announced it on 15 October. About 11.18 million member records were involved.

Was my credit card exposed?

The company says it does not hold card numbers, so they were not in the leaked data. Passwords have not been confirmed as leaked. Names, email addresses, phone numbers, birth dates, gender, prefecture and some account flags were.

How did the attackers get in?

That has not been disclosed. The company is investigating with outside specialists. Any claim about the method in social media or unofficial posts should be treated as unconfirmed until the company or a regulator says so.

Has the data been posted online?

None of the sources we read report it being posted or sold. The company says the data leaked outside its control. If that changes, the company or major Japanese press would be the place to confirm it.

Does Burger King Japan have to notify me?

Under APPI, a leak by unauthorised access affecting more than 1,000 people must be reported to the PPC and notified to the individuals affected. ScanNetSecurity reports the company is notifying affected members by email.

What should a consumer app team do first after reading this?

Add a test that one member cannot read another member's record, check logs for bulk reads, and list every API host that can reach production data.

Would Safeguard have prevented this?

We cannot say, and we do not claim it would have. The cause is unknown. Safeguard helps you know and fix the components in your backend and images; it does not test your API authorization logic or detect an intrusion in progress.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Burger King Japan. Each is a real Safeguard session, and each intro says how the flow applies to a member app backend.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a member API, you would run /scan . in the backend repository, ask the assistant to upgrade a vulnerable framework or library and add the member authorization test from step 3, and approve each command as it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For an app team, you would pick the member API folder, ask for the dependency upgrade and the rate limit change, and approve or deny each edit yourself.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. During an incident weekend, the on-call engineer could approve a rebuild of the member API image from a phone.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For a related Japanese incident, read our post on IDCF Cloud ransomware and third-party risk. For the wider month, see October 2026 security incidents and what would have helped, and for fast scoping with SBOMs, finding affected products fast.

Quick check

Sources

• Impress Watch: Burger King official app leaks about 11.18 million member records (Japanese)
• ScanNetSecurity: Unauthorised access to Burger King official app, about 11.18 million member records leaked (19 Oct 2026, Japanese)
• BleepingComputer: Burger King Japan data breach exposes 11 million customer records
• Security Affairs: Burger King Japan data breach impacted 11 million customers
• ScanNetSecurity: Burger King official app member information leaked after unauthorised access (31 Oct 2024, Japanese)
• Personal Information Protection Commission: Responding to leaks and reference materials (Japanese)
• Personal Information Protection Commission: Mandatory leak reporting and notification to individuals (Japanese)
• Personal Information Protection Commission: APPI Guidelines, General Rules (Japanese)
• OWASP API Security Top 10 (2023)
• Council of Anti-Phishing Japan (Japanese)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.