Summary
Capcom says no leak of passwords members set themselves has been confirmed. Even so, login passwords on some accounts had been changed without authorization. In a second report the next day, it said that for some of those accounts, a third party accessed the account pages of its online store, which uses the same ID, exposing addresses and purchase history. Which procedure changed the passwords, and how the changes relate to the store access or which came first, have not been disclosed. With a shared ID, a single password change that goes through can open every service that ID reaches to someone else.
A pre-execution check means matching, before a password change takes effect, whether the owner made it, and keeping a record. Detection means noticing unauthorized access after it happens. The dates below are when Capcom confirmed or disclosed each point, not when the changes or the access took place.
Store account pages accessed for 19 of them
What got through
- What got through
- Changes to CAPCOM ID login passwords. Passwords on 196 accounts were changed without authorization. No leak of passwords members set themselves has been confirmed. The 196 passwords were reset (Capcom first report).
- Online-store account pages
- Of the 196 accounts whose passwords were changed without authorization, for 19 (Japan) a third party accessed the account pages of e-Capcom, the online store, exposing addresses, purchase history and more (Capcom second report). How the password changes relate to this access, and which came first, have not been disclosed.
- What reached the receiving side
- In general, a password change arrives either as an action from a logged-in session or as one that passed the reset procedure. Passing the procedure does not show that the account’s owner made the change.
- Not disclosed
- The method of intrusion (the company says it has identified it), when the intrusion began, which procedure changed the passwords (the reset flow or another function), whether owners were notified of the change, whether multi-factor authentication was in place, and why it was 196 accounts.
Pre-execution check
Whatever the route, the condition for telling them apart is that whoever applies password and email changes matches each change to the owner, using a contact or key registered before the change, before it takes effect.
With a shared ID, a single password change that goes through can open every service that ID reaches to someone else.
- Who approves
- The account owner. The change is approved through the contact registered before the change (email address or phone number) or a key on the owner’s device (such as a passkey), in a form that neither the server receiving the change nor the change screen itself can produce.
- Where it is checked
- The server that applies password and email changes. Changes from any procedure — the logged-in screen, the reset flow, support desks or admin functions — are checked at one point before they take effect. A change that does not match an approval is held, not applied; with a shared ID, services holding addresses or purchase history stay closed while it is held.
- What is recorded
- Which account’s change came through which procedure, and which approval applied it.
Blocking and resetting are remedies after the fact. Account details being changed without confirming the owner is an issue shared with the Instagram support-channel takeover (asking the AI support bot was enough to have the registered email switched to the attacker’s).
What Lemma does
Lemma builds the pre-execution check into the side that applies password and email changes. It does not look for intrusions; it confirms, before a change takes effect, that the change rests on the owner’s approval.
Industries and operations to watch
- IndustryMedia & content
- Games, video, e-books and other businesses where one member account opens several services and apps. Member counts are large, and account changes are often processed automatically.
- IndustryServices & retail
- Online stores whose member accounts hold addresses, phone numbers, purchase history and saved delivery addresses. When login runs through a shared ID, a change on the ID side becomes the way into the store.
- OperationAccounts & permissions
- Managing changes and resets of member passwords and email addresses.
Current controls vs Lemma
This disclosure covers 196 unauthorized password changes on CAPCOM ID and, for 19 of those accounts, access to the online store’s account pages; the method of intrusion and the procedure used to change the passwords have not been disclosed. So it is not known whether the changes here fall in column 1 (changes through a procedure) or column 3 (direct rewrites). Column 2 covers entering another service after a change; whether the 19 cases of access fit it has not been disclosed either. The last column corresponds to the exposure of 11.77 million email records.
| Control | Changes through the screen or reset flow | Entering other services right after a change | Direct rewrites in the database or admin functions | Taking registered data |
|---|---|---|---|---|
| Strong, unique passwords | Partial | Partial | Not relevant | Not relevant |
| Login MFA | Partial | Partial | Not effective | Not relevant |
| Notice after a change (to the registered contact) | Partial | Partial | Not effective | Not relevant |
| Detecting and blocking unauthorized access | Partial | Partial | Partial | Partial |
| Lemma (pre-execution check) | Effective | Effective | Not effective | Not effective |
Strong passwords and MFA protect login; if the reset flow does not require them, that path stays open. A notice after a change gives the owner a way to notice later. Detection and blocking work after the fact. Lemma checks the change itself, not the login, against the owner’s approval before it takes effect.
Note: Lemma’s check works only when it is built into the server that applies password and email changes, every change — from the logged-in screen, the reset flow, support or admin functions — passes the same check, and the contact or key used for approval sits apart from the system that receives the change. It passes if the contact registered before the change has itself been taken over, or if the database or admin functions are rewritten directly. Nor does this check stop registered data from being taken. The table compares what each control checks; it does not show whether this incident would have been stopped. Lemma does not detect or prevent intrusions.
Three things to check in your organisation about changes to member accounts
- When a member’s password or email address changes, does a notice also reach the contact registered before the change?
- For services reached with a shared ID that show addresses or purchase history, do you confirm the person again when they enter right after a password change?
- If passwords change on many accounts in a short time, can you notice and stop the changes?
Facts and timeline
- Service
- CAPCOM ID is Capcom’s registered shared account for its web services and some online games (Capcom). Using e-Capcom, Capcom’s online store, also requires a CAPCOM ID (e-Capcom user guide).
- Information exposed
- Email addresses and system-specific identifiers (account creation date and time, last login date and time, number of logins, client IP address at last login) for 11,774,247 records worldwide. For 43 of them, date of birth, gender, country/region and nickname were also exposed. Credit card information was not included (Capcom first report).
- Unauthorized password changes
- Of the 11,774,247, login passwords were changed without authorization on 196 accounts. No leak of passwords members set themselves has been confirmed. The 196 passwords were reset (Capcom first report).
- Online-store account pages
- Of the 196 accounts whose passwords were changed without authorization, for 19 (Japan) a third party accessed e-Capcom account pages, exposing name, name in phonetic script, phone number, postal code, address, gender, date of birth, purchase history, e-Capcom inquiry history and saved address book. Credit card information was not included. The company says no information exposure from the unauthorized password changes was found for the other accounts (Capcom second report).
- Path
- Capcom says it has identified and addressed the method of attack. What that method was has not been disclosed (Capcom first report).
Glossary
CAPCOM ID — Capcom's registered shared account for its web services and some online games. Capcom's online store, e-Capcom, is also used through CAPCOM ID.
System-specific identifiers — In Capcom's disclosure: account creation date and time, last login date and time, number of logins, and the client IP address at last login.
Account page — The page on an online store where members view and change their address, purchase history and saved delivery addresses.
Timeline
- Capcom finds traces suggesting unauthorized access to CAPCOM ID, immediately blocks the access and begins investigating. The same day it confirms unauthorized access occurred and starts emergency measures and work to identify the method of attack.
- Capcom sets up an internal response headquarters. It finds that some registered information was exposed and that passwords on some accounts were changed without authorization, and reports to its external Security Oversight Committee.
- Reports to the police and the Personal Information Protection Commission.
- Publishes its first report (timely disclosure). Says emergency measures and the identification and handling of the attack method are complete, and services using CAPCOM ID remain available.
- Second report: for 19 of the 196 accounts whose passwords were changed without authorization, e-Capcom account pages were accessed. Says the investigation of the scope is complete.
The facts rest on Capcom’s first and second reports (both primary, timely disclosure, in Japanese and English on its site). The first report says identification and handling of the attack method is “complete” but does not describe it. The second report says the store’s account pages were accessed for 19 of the 196 accounts whose passwords were changed, but does not say which came first or whether the changed passwords were used. What has not been disclosed does not mean no measure was in place. As of November 2, no third report appears in the company’s news list.
After disclosure
- Capcom: Reset the 196 passwords and is notifying affected members in turn. Set up dedicated inquiry lines in Japan and abroad. Says it will keep monitoring CAPCOM ID and related services and take preventive measures based on the cause.
- Advice to members: Warns that the exposed data may be used for emails, text messages or calls impersonating Capcom or related parties, and asks members not to open links or attachments.
Sources
- Primary, timely disclosureCapcom Notice and apology regarding customer information leaked through unauthorized access
- Primary, timely disclosureCapcom Notice and apology regarding customer information leaked through unauthorized access (second report)
- Primary, company disclosureCapcom “Notice and Apology Regarding Customer Information Affected Through Unauthorized Access”
- Primary, company disclosureCapcom “Update to Notice and Apology Regarding Customer Information Affected Through Unauthorized Access”
- Primary, user guidee-Capcom User guide (Japanese)
1 more (reporting, analysis)
- PressASCII.jp Capcom leaks over 11.77 million customer records; unauthorized access to CAPCOM ID, unauthorized password changes too
References: “The last layer left in AI-era cyber defense”