Japan's Data Breach Wave: 11.7M Capcom Accounts, and Why Your Vendor Is the Real Risk

Japan is in the middle of a data breach wave. Gamers, shoppers, doctors. Millions of people in a few weeks. Almost none of it makes the news outside Japan.

I've run a crowdsourcing platform in Japan for 22 years, so I read these notices closely. The part that matters to you, wherever you are, is how the breaches spread: a lot of companies didn't get hacked. Their vendor did.

The video covers the main cases in five minutes. This article goes through each company's own notice: what exactly leaked, how long attackers were inside, what customers were told to rotate, and the countermeasures Japan's computer emergency team published.

I also made a video of this.

The short version

• Capcom: 11,774,247 CAPCOM ID records worldwide. Email addresses and login details. The attacker changed the password on 196 accounts.
• Studio, a no-code website builder: attackers were inside its cloud from September 30 to October 1. API keys, tokens, webhook URLs and form submissions may have been read, even the encrypted ones, because the decryption key was accessed too.
• Studio's breach became its customers' breach. SmartHR disclosed 2,012 people from its contact forms. On my own map of October, 18 organizations announced leaks through Studio.
• E-Store's final report: attackers were inside its e-commerce platform for more than two months, from May 21 to August 1. About 23.36 million people across 7,858 shops.
• JPCERT/CC says there is no single technique. It lists five patterns, including stealing API keys from public apps and reusing API keys stolen from other companies.
• Today: list every service that holds your keys, rotate them when that service is breached, and stop storing secrets and data in tools that don't need them.

How big is this

A tally by the security firm Macnica, reported by The Hacker News, counted 119 incidents in Japan from January to early October, 81 of them since July.

I also built my own map of October. It covers 163 organizations in Japan that announced a breach, a break-in or a ransomware attack that month (166 entries), each taken from the organization's own announcement, as of October 26.

The second biggest group isn't about the organization's own systems at all. 65 entries came through a service or contractor the organization used.

JPCERT/CC, Japan's computer emergency response team, issued a warning on October 8 and updated it on October 23. Japan's privacy regulator, the Personal Information Protection Commission, issued its own warning on October 7.

Capcom: 11,774,247 accounts

Yes, the Resident Evil and Street Fighter company. Capcom's notice of October 22 breaks the number down:

What	Records
Email address, plus account creation time, last login time, number of logins, and IP address at last login	11,774,247 (worldwide)
Of those, also date of birth, gender, country or region, and nickname	43
Of those, CAPCOM ID password changed by the attacker	196

Capcom says it has not confirmed that any password customers set themselves was compromised. The 196 changed passwords have been reset. Credit card information was not included.

How it unfolded:

• October 19: Capcom detects suspicious activity, blocks it, and confirms unauthorized access the same day
• October 20: an internal response headquarters is set up. The changed passwords are found
• October 21: reported to the Osaka Prefectural Police and the Personal Information Protection Commission
• October 22: public notice

Capcom says it has identified and addressed the attack method, but it has not said what it was. Games and CAPCOM ID keep working. The practical risk for players is phishing: Capcom warns that the leaked email addresses could be used for fake emails pretending to be Capcom.

Studio: the decryption key went too

Studio is a popular no-code website builder in Japan. This is the one developers should read closely.

Date	What happened
September 30 to October 1	A third party uses a vulnerability in a Studio feature to access its cloud environment
October 13	Studio confirms the access
October 13 to 14	Vulnerability fixed, entry point closed, outside access to the data blocked
October 16	First notice
October 17	Studio replaces the key used to encrypt form submissions and API keys, and starts re-encrypting old data

What may have been exposed, for all registered customers:

• Account information: username, email address, hashed password
• Site content: Design Editor and CMS content, form submissions, reCAPTCHA v3 settings, webhook notification URLs
• Live Preview URLs for unpublished pages
• Credentials stored in settings: third party API keys and tokens, passwords for protected pages, Google Sheets integration credentials, custom proxy keys

And then the sentence that matters most. Those secrets "may have been read, even where they were stored encrypted, because the key needed to decrypt them was also accessed during the same unauthorized access."

Two more details are easy to miss. Form responses sitting in the trash but not completely deleted were included, and so were responses hidden from the dashboard because they went over the plan's limit. Responses sent while "Save form responses to Studio.Design" was turned off were not included.

Studio also says the credentials the attacker obtained had permission to change data, and it found no record of data being modified or deleted. And it is honest about its own fix: replacing its keys does not protect what may already have been taken.

What Studio asked customers to do

This list is the most useful part of the whole wave, because it's what you would face if any tool that holds your keys got breached.

If you use	Do this
Email and password sign-in	Change the password, and any other site where you reused it
Live Preview URLs	Delete them and issue new ones
API integrations with third party keys	Rotate the keys at the third party
Password-protected pages	Change the page password
Webhook notifications	Switch to a new notification URL
Google Sheets sync	Stop the sync, remove Studio's access in your Google Account (myaccount.google.com/linkedapps), then set it up again
Custom proxy	Switch your server to the new proxy key, then tell Studio so it revokes the old one (within 30 days)
Forms	Studio sends details. Site owners may have to notify the people who filled in the form

One breach becomes your breach

SmartHR, a big HR software company, used Studio for some of its websites. It disclosed 2,012 people who had used those contact forms, and named Studio's vulnerability as the cause. One detail: some of the affected sites belonged to group companies whose services had already shut down. The old contact forms were still holding the data.

SmartHR also says the data in its own HR product was not part of this. Only what people typed into forms on the Studio sites.

On my map, 18 organizations announced leaks through Studio, including the Digital Agency, the Japanese government's own agency for digital services.

The same thing happened with email.

JR Shikoku, a rail company, used blastmail, a bulk email service by Rakus Lite Cloud, for its tour newsletter. It disclosed up to about 30,000 subscribers: name, date of birth, address and email address. It says the newsletter currently can't be sent. On my map, blastmail itself is listed with 344 affected contracts.

Other vendor cases from October, from each organization's own notice:

Organization	Through	Scale
Customers of Ymirlink's Cuenote FC (email delivery)	A library vulnerability let the attacker take a support staff member's credentials	51,628,280 records across 49 client systems (cumulative)
Customers of IDC Frontier (cloud)	Ransomware at the cloud provider	495 companies and local governments affected
Daiichikosho (karaoke)	One PC at a contractor handling its customer data was infected	About 8.72 million records
Ride On Express (food delivery)	The company running its servers was hit by ransomware	Up to about 6.5 million records
Osaka Metropolitan University	A subcontractor of its maintenance contractor NEC was attacked, and its legitimate account was used to get in	About 130,000

You didn't get hacked. Your vendor did. And now it's your breach, your notice and your customers' phishing emails.

M3, Mr Max and E-Store

M3, a big medical platform: on October 14 it found unauthorized access to "MR-kun", its service for pharmaceutical companies. Leaked: 25,775 m3.com members and others (6 with email addresses), and 2,260 pharma company staff (264 with email addresses). Names, workplaces and service usage information. The member count includes some doctors' information that pharma companies had entrusted to M3. Login passwords and points were not included.

Mr Max, a discount retailer: suspicious access to the servers of its app and online store on the evening of October 3. It stopped the service and cut outside access the same day. A third party misused a function of the software the service runs on. Up to 1,735,154 members: member ID, name, email address, phone number. Mr Max says addresses, dates of birth, card details, passwords and purchase history did not leak.

E-Store, which runs the ShopServe e-commerce platform, published its final report on October 16.

Item	From the final report
How	A vulnerability in an application on its servers let the attacker run a program and send database contents out
How long	May 21 to August 1, 2026
People	About 23,356,000 (shoppers, members, shop operators and affiliates, partly deduplicated)
Shops	7,858, including shops that had already left the platform
Card data	About 2,096,900 people with cardholder name, first 6 and last 4 digits and expiry date. No full numbers, no security codes
Shop side	ShopServe admin login IDs and passwords
Afterwards	No other entry route and no backdoor found. Two factor authentication added to admin screens

More than two months inside before anyone noticed.

How attackers are getting in

JPCERT/CC is careful here. It says the incidents don't share one technique, and what it knows is limited and fragmented. But it lists the patterns reported to it:

Case	Pattern
A	Scanning each target for many known vulnerabilities, or for config and backup files left exposed
B	API abuse: taking apart public smartphone apps to find endpoints and keys, then calling internal APIs the app's screens never call (changing user permissions, creating accounts, probing with missing or malformed tokens, blind NoSQL injection). Plus reusing API keys stolen from other systems
C	A SQL injection vulnerability in the BI tool Metabase (CVE-2026-72898)
D	WAR files placed on application servers reachable from public web servers, carrying a simple JSP web shell
E (added October 23)	Attacks run with penetration testing platforms such as Cairn, CyberStrikeAI and ARTEX, including against internet facing WSUS servers

It also points out that systems never meant for the public were breached: BI tools and internal employee systems. The JPCERT/CC page lists the source IP addresses, user agents and TLS fingerprints it has seen, so you can search your own logs for them.

Its countermeasures for APIs:

• Rate limit API requests, with separate limits for login, password reset, SMS sending and search
• Enforce access control on every endpoint, including the ones you think are private
• Give API users and tokens only the permissions they need
• Set expiry dates on tokens, avoid long lived ones, and be able to revoke them fast

And the general ones:

• If your users are in one region, restrict access by region
• Patch known vulnerabilities
• Review how far an attacker could move after taking a web server
• Stop exposing admin functions the business doesn't need on the internet
• Don't keep data past its legal retention period or after its purpose is over

What I take from this

Look at JPCERT's case B again: API keys stolen from other companies. Now look at Studio: API keys, tokens and webhook URLs, possibly all readable. That's exactly the kind of thing that turns one breach into ten.

Three things to do today

1. List every service that holds your API keys or tokens. Website builders, form tools, email services, analytics, anything with a webhook. If one of them announces a breach, rotate those keys that day. Use Studio's table above as your checklist: keys, webhook URLs, linked Google access, proxy keys, preview links, page passwords.

2. Don't store secrets or data in a tool that doesn't need them. Every place a key lives is another place it can leak from. The same goes for data. If your forms already send responses to email or a spreadsheet, check whether the builder also needs to keep a copy. Empty the trash. Close the forms of services you've shut down. SmartHR's old forms still held data.

3. Patch the boring stuff. BI tools, admin panels, internal dashboards. Attackers aren't only going after your main app. If an admin screen doesn't need to be on the internet, take it off.

Have you had to rotate keys because a vendor got breached? Tell me in the comments on the video. I read every one.

Sources: Capcom's notice (October 22, 2026, English edition), Studio.Design's notice and information portal (October 16, updated October 18 and 23), SmartHR (October 22), JR Shikoku (October 22), M3's second notice (October 23), Mr Max (October 6), E-Store's final report (October 16), JPCERT/CC alert JPCERT-AT-2026-0030 (October 8, updated October 23), and the Personal Information Protection Commission's warning (October 7). The Macnica tally is as reported by The Hacker News. The October map and the vendor table are my own tally from each organization's announcement, as of October 26 and 27, 2026. Read November 2, 2026.