Key takeaways
- We analyzed all 37 breaches of a million records or more disclosed in Japan in 2026, from our running list, as of October 24.
- 22 were disclosed in October alone, and 26 since mid-September. In the eight months to August, there had been 11.
- 11 of 37, nearly one in three, were breaches at a vendor or platform holding data for other companies' customers: e-commerce platforms, booking systems, email delivery services, a cloud provider and a contractor's PC.
- 18 of 37 companies have not said how the attackers got in, or say they are still investigating. Of the rest, the most common route is an exploited vulnerability (9), followed by misuse of APIs, app or admin functions (4) and ransomware (3).
- 11 say data may have leaked rather than confirming it, and the counts mix records, accounts, people and cumulative totals. In our view, the numbers say more about how many organizations are exposed than about how many people are affected.
How we counted#
Our list includes every breach first disclosed in 2026 by an organization in Japan where the organization's own figure is one million records, accounts or people or more, including "up to" figures. The classifications below are ours, based on each organization's notices as summarized in the list and in our articles. Where a notice is vague, we have put it in the most cautious category. The data is as of October 24, 2026, and we will update this analysis as the list grows.
When: a wave that started in September#
| First disclosed | Breaches of 1 million or more |
|---|---|
| January–March | 0 |
| April | 1 |
| May | 0 |
| June | 3 |
| July | 2 |
| August | 5 |
| September | 4 |
| October (to the 24th) | 22 |
| Total | 37 |
From April to August, Japan saw about two large breaches a month. Since September 16, when the screenshot service Gyazo disclosed 23.6 million records, there have been 26. October alone, with a week still to go, has produced more than the rest of the year combined.
Two things are happening at once, and the numbers cannot separate them. Attacks have clearly increased: JPCERT/CC, GMO Cybersecurity by Ierae and Microsoft have all described automated, AI-assisted campaigns running since late September. But disclosure has changed too. After the first large cases, the government asked companies to report and share, and many organizations reviewed their systems. Some disclosures this month, such as the photo marketplace Snapmart's, came out of exactly those reviews.
Who: one in three was a vendor or platform#
| Whose system was breached | Breaches | Examples |
|---|---|---|
| The organization's own service | 26 | Sagawa Express, Capcom, Times Car, SourceNext, Bookoff |
| A vendor or platform holding data for other companies' customers | 11 | ShopServe and FutureShop (e-commerce), EPARK and Fines (booking), Temairazu (hotels), Yumil Link and the IDCF email service (email delivery), Arcadia (disaster alerts), KDDI's mail system for ISPs, Rideon's server operator, Daiichikosho's contractor |
The list understates this. Several of the month's most consequential vendor breaches fall below a million records or have no count yet: the website builder Studio, whose customers range from startups to the Digital Agency; the email delivery service Blastmail, with all its customers' details taken; NEC's contractor, whose accounts were used to encrypt customers' servers; the trading system vendor behind Iwai Cosmo Securities; and the security vendor Digital Arts.
In our view, this is the most important pattern in the data. A vendor breach multiplies: one intrusion produces dozens or hundreds of notices, each from a company that did nothing wrong in its own systems, and each still legally responsible for the data it handed over. It is why joint reports to the privacy regulator, filed by the vendor and its customers together, have become routine this autumn, from Studio and Arcadia to Sagawa, Blastmail and FutureShop.
How: half have not said#
| What the organization said about the route | Breaches |
|---|---|
| An exploited vulnerability in software or a web system | 9 |
| Misuse of APIs, app functions or admin functions | 4 |
| Ransomware | 3 |
| Stolen credentials | 1 |
| Malware on a contractor's PC | 1 |
| A lost storage device | 1 |
| Not stated, or still under investigation | 18 |
Eighteen of 37 organizations have not said how the attackers got in. Some say the investigation is ongoing; some say they will not disclose the method to avoid helping other attackers; a few, such as NTT Solmare for Comic Cmoa, say they have identified the route but do not describe it. Macnica's security research center, counting a wider set of 119 web breaches this year, found that about 80% of disclosures do not explain the cause.
Even "vulnerability" often means little more than that. Few notices name the product, the type of flaw or whether a fix exists. Among the exceptions: Arcadia published a minute-by-minute account of a path traversal, a secret key read from a config file and a backdoor, and Times Car's final report described how the attackers used information found inside the web system to reach the database.
In our view, this is the gap that most limits defenders. JPCERT/CC's advisory, with attack patterns and IP addresses, has been more useful to other organizations than all 18 silent notices combined. There is a real argument for holding back details until a hole is closed. But once it is closed, a sentence on the type of weakness, such as an exposed admin function, an unpatched product or a misconfigured API, costs the victim little and helps the next one a great deal.
What: "may have" and other caveats#
| Status in the notice | Breaches |
|---|---|
| Data taken or confirmed leaked | 24 |
| Data may have been viewed or taken | 11 |
| Data viewed | 1 |
| Storage device lost | 1 |
"May have" is not hedging for its own sake. Under Japan's privacy law, the possibility of a leak caused by unauthorized access is enough to require a report to the regulator and notice to the people affected, as we explain in our guide to the notification rules. Companies often cannot rule a leak out quickly, so they report the possibility.
The counts are not comparable either:
- Records, accounts and people are mixed. ShopServe counts people after removing duplicates; Times Car counts accounts; EPARK says its records cannot be converted into people.
- Some figures are cumulative. Sagawa Express's 53.23 million counts every waybill, with the same person appearing many times. Yumil Link's 9 million is an estimated cumulative total across five systems. Most of Comic Cmoa's 4.2 million came from log files.
- What leaked ranges from email addresses only (dip) to driver's license images (Times Car), passwords (SourceNext), estimated tax deductions (Furusato Choice) and parcel histories (Sagawa, Yamato).
Added up, the 37 figures come to about 320 million. That number means little: Japan has fewer than 125 million people, and the same person appears in many lists. In our view, the useful reading is different: a large share of people in Japan who shop, travel or ship online are likely to be in at least one of these breaches, and the risk that follows is targeted phishing using real details, not a single catastrophic leak.
What this means for practitioners#
- Inventory your vendors, not just your systems. One in three large breaches this year happened at a vendor or platform. Know which of them hold your customers' data, how much, and since when, and delete what they no longer need to keep.
- Treat app APIs and admin functions as internet-facing. The misuse of APIs and admin functions is the second most common route we could identify, and JPCERT/CC's advisory shows how attackers find them by analyzing public apps.
- Prepare to say what happened. Decide in advance what you will be able to disclose about the route once a hole is closed. Half of this year's largest breaches have told other defenders nothing.
- Plan for "may have". Most notices go out before the facts are clear. A notice template, a joint-reporting arrangement with key vendors and a way to reach former customers save days when it matters.
- Do not wait to find out. In a Teikoku Databank survey this month, 14.8% of Japanese companies said they did not know whether they had ever had a leak.
Japanese terms at a glance#
| Japanese | Reading | Meaning |
|---|---|---|
| 情報漏えい | jōhō rōei | Data leak, data breach |
| 漏えいのおそれ | rōei no osore | Possible leak (the reporting threshold) |
| 委託先 | itakusaki | Contractor, vendor |
| 連名報告 | renmei hōkoku | Joint report (by a vendor and its customers) |
| 原因 | gen'in | Cause |
| 延べ件数 | nobe kensū | Cumulative count, including duplicates |