Breaches of Member Systems Keep Coming: What the Disclosed Incidents Have in Common, the Methods JPCERT/CC Describes, and What to Check Now

From September into October 2026, unauthorized access to systems used by members and app users, and the resulting leaks of personal information, have been disclosed one after another. Some involve more than 10 million records. JPCERT/CC issued an advisory on unauthorized access to organizations in Japan on October 8 and updated it on October 23 (JPCERT-AT-2026-0030, in Japanese).

This article is for companies that run user-facing systems, and for the people who operate them. It covers the disclosed incidents, the methods JPCERT/CC describes, and what to check now. Sources are cited next to each statement. For many incidents the cause was still under investigation when disclosed, so the cause of each incident cannot be pinned on a particular method, and this article does not try to. The information is current as of October 25, 2026 JST.

Key points

• Most of these incidents involve unauthorized access to member-management systems or to the account services behind an app, with record counts from roughly 900,000 to more than 10 million.
• The disclosed items center on names, email addresses and phone numbers. In many incidents, login passwords and credit card numbers are said not to be included. Still, this information can be used for phishing and impersonation.
• For many incidents, the cause had not been identified at the time of disclosure. Within what I was able to check, I found no official statement of a common cause or of a single attacker behind them.
• JPCERT/CC describes five methods that have been confirmed: scanning for known vulnerabilities, abuse of APIs, a Metabase vulnerability, web shell placement, and abuse of AI penetration-testing platforms.
• JPCERT/CC asks that BI tools and employee-facing management systems be checked too, not only the apps used by the general public.

The main disclosed incidents

This is based on each company’s disclosure and press reports. Record counts are given as disclosed. The cause column shows only what has been disclosed.

The counts are record counts. They are not necessarily the number of unique people.

What the incidents have in common

These three points are my own observations.

• The targets are systems that users interact with directly: membership, apps, reservations. A great deal of personal information is concentrated in one system, so a single break-in produces a large count.
• Detection and disclosure were quick in several cases. For example, Yakiniku King disclosed three days after confirming unauthorized access. But the cause and entry route were often still unknown at the time of disclosure.
• Even when what leaked is names, email addresses and phone numbers, it is more than enough for phishing and impersonation. The absence of passwords does not mean the harm is small.

The five methods JPCERT/CC describes

JPCERT/CC’s advisory groups the confirmed attacks into five cases. It does not tie them to the individual incidents above.

• Case A (scanning for known vulnerabilities): the attacker scans each target for known vulnerabilities in a range of software and tries to exploit them. Some attacks exploit poor device management rather than vulnerabilities, with theft of configuration files and backup files given as examples
• Case B (abuse of APIs): the attacker analyzes a publicly available smartphone app, identifies API endpoints and keys, and goes after internal APIs that the screens cannot reach. Changing user privileges, creating unauthorized accounts and identifying account information through NoSQL injection are listed. API keys stolen from other systems are sometimes used
• Case C (Metabase): an SQL injection vulnerability (CVE-2026-72898) is being exploited through crafted API requests. JPCERT/CC issued a separate advisory on it on August 14
• Case D (web shell placement): there are cases where a WAR file containing a malicious JSP was placed on an application server reachable from a public web server
• Case E (abuse of AI penetration-testing platforms, added October 23): tools such as Cairn, CyberStrikeAI and ARTEX are being abused, and internet-facing web applications and WSUS servers are being targeted

JPCERT/CC also lists suspicious source IP addresses on the page and recommends checking your logs for access from them. It cautions, though, that some may be legitimate use, and that access through Tor exit nodes and residential proxies has also been seen, so IP addresses should not be used alone but combined with other indicators.

What to check now

This follows the measures JPCERT/CC lays out, arranged in order.

Today

1. List your user-facing systems (membership, apps, reservations, points). For each, write down whose personal information it holds, what kind and how many records
2. Check whether any API, admin function, BI tool or employee-facing system that the public should never use is exposed to the internet. JPCERT/CC asks that services and functions not needed for the business be taken off the internet
3. Check whether the middleware and products you use have known vulnerabilities. If you use Metabase, for example, check JPCERT/CC’s advisory

This week

4. Put rate limits on your APIs. For high-risk functions such as login, password reset, SMS sending and search, set separate usage limits (JPCERT/CC)
5. Enforce access control on every endpoint, including non-public APIs. Give API users and tokens only the minimum privileges. Give tokens an expiry, and be able to revoke any token suspected of leaking right away
6. Check your logs for the IP addresses on JPCERT/CC’s list. If you find one, do not judge on that alone; investigate together with other logs
7. Review how you detect unauthorized access and what you do first when you detect it. Check that you would notice bulk retrieval of account information or repeated access in a short time

This month

8. Delete data past its retention period or no longer needed for its purpose (JPCERT/CC). Information you do not hold cannot leak
9. Prepare to urge users to protect themselves from secondary harm if a leak occurs. Be ready to issue guidance on multi-factor authentication and warnings about impersonation emails right away (JPCERT/CC)
10. Confirm roles with your development contractors and vendors. Decide who handles updates, log monitoring and first response for each system. For example, Yakiniku King says it is strengthening measures together with its developer and affiliated companies (Business+IT)

What users can do

11. If your email address or phone number may have leaked in these incidents, be careful with emails, text messages and calls that pretend to be from these companies. Times Car says it never asks for passwords or card information by email or SMS (Times Car)
12. If you reuse passwords, change them. Turn on multi-factor authentication where a service offers it

What I could not confirm

• For many incidents the cause had not been identified at the time of disclosure. This article does not speculate about causes
• I could not confirm the cause for Times Car, as the third-report page does not state it. The report says a further update is planned in about two weeks
• The Lawson app reservation count differs between reports, and I could not confirm a settled figure
• GMO Research & AI’s cause (a software vulnerability) rests on press reports. I could not check the original company announcement
• The Burger King details rest on a press report (Impress Watch). I could not check the company’s original announcement

Related articles

• Two Critical GitLab Flaws, Not One: Why the October 12 Fix Is Not Enough: A flaw in self-hosted GitLab: checking your version, and checking for compromise
• As Breaches Mount in Japan, What Leaders Should Decide First: Zero Trust and Security in the Age of AI: What executives should decide first
• Earning Cybersecurity Certifications in the US, Stage by Stage: Exams, Exam Fees and Study Costs (October 2026): A US roadmap for people who want to prepare for cases like these: exams by stage, with exam fees and study costs

If you need help checking your member systems and APIs, or taking stock of what is exposed, get in touch below.