CAPCOM ID Breach: 11.7 Million Records Exposed and 196 Passwords Changed

On October 22, 2026, Capcom confirmed that an unauthorized party accessed 11,774,247 CAPCOM ID records and that the login passwords on 196 accounts were changed without the owners’ consent. Credit card information was not among the affected data, and Capcom says it has not confirmed that customers’ original passwords were compromised.

The 11.8 million figure gets the headlines. I think the 196 password changes and the 43 deeply profiled accounts say more about what went wrong and who is at risk. CAPCOM ID is the shared sign-in layer for Capcom’s web services, community forums, and online multiplayer, so a breach there reaches everything attached to it.

What Capcom disclosed about the CAPCOM ID breach

Capcom’s notice describes three groups of affected data.

The first is 11,774,247 records containing email addresses and system-specific account information. The second is a much smaller set of 43 records with deeper personal details: date of birth, gender, country or region, and nickname. The third is 196 accounts whose login passwords were changed without authorization.

Capcom also said credit card data was not involved and that the passwords customers originally chose have not been confirmed as compromised. That second point matters for the threat model. It suggests the attackers did not leave with a password database, which pushes the investigation toward how the system accepted changes it should have refused.

What the exposed login metadata gives an attacker

The system-specific information covers the date and time each account was created, the date and time of its last login, the total number of logins, and the IP address used at that last login. For a single account this is routine operational data. Across 11.7 million accounts it becomes a behavioral map of Capcom’s player base.

An attacker holding that dataset can separate legacy accounts, which probably carry years of purchases and progression, from newly created ones that may be easier targets for social engineering or credential testing. Most breach coverage fixates on passwords and payment data, and this incident shows why login metadata deserves the same attention.

Why IP addresses and login timestamps still matter

An exposed IP address does not reveal a player’s exact location. VPNs, carrier-grade NAT, and dynamic address assignment all blur it. The data still has value for correlation. Attackers routinely match breached IP addresses against public geolocation databases, social media check-ins, and other leaked datasets to build profiles of targets they care about.

The sharper risk is phishing. An email address, a precise last-login time, and a rough region are enough to send a fake “suspicious activity” alert minutes after the victim’s real session, naming their actual region. The message contains details only Capcom should know, so the usual suspicion drops and a click on the fake login page becomes far more likely.

196 unauthorized password changes: an integrity failure

Confidentiality and integrity are separate parts of the CIA triad, and failing one does not mean failing the other. A password disclosure is a confidentiality failure: someone obtained the secret needed to log in. An unauthorized password change is an integrity failure: the system accepted a change the account owner never made.

Because Capcom has not confirmed that original passwords were compromised, the attackers may never have needed them. That points to a weakness in authorization, session management, or account recovery. Capcom has not said which. Everything below is hypothesis, not finding.

Broken object level authorization and session hijacking

Broken Object Level Authorization (BOLA), also called Insecure Direct Object References (IDOR), is a leading suspect in cases like this. An API can authenticate a user correctly and still fail to check whether that user may modify the specific account ID in the request. If the password change endpoint used predictable user IDs or weakly validated session tokens, an attacker with one low-privilege account could have rewritten credentials on others.

Session hijacking or fixation would produce the same result by a different route. With a valid session token, obtained through cross-site scripting on a peripheral Capcom web property or a malicious browser extension, an attacker can open the account settings page and change the password exactly as the owner would, without ever knowing the old one.

Account recovery abuse

Recovery flows are risky by design, because they exist to bypass the current password. Predictable reset tokens, missing expiration, host header injection in the reset email, or weak rate limiting on the request endpoint would each let an attacker force resets on chosen accounts and capture the resulting tokens.

The count itself is a clue. Only 196 accounts were modified, not millions, which fits a targeted or manual effort, an automated attack throttled by a rate limit, or a compromised administrative or service account with narrow but privileged write access to user records. The most important forensic question for Capcom’s incident response team is whether the changes ran through the public application layer, an internal administrative API, or direct database manipulation.

The 43 records with date of birth, gender, and nicknames

Forty-three records is a rounding error against 11.8 million, but the people in them face a different kind of risk. A date of birth and gender rarely work as authentication secrets on their own. Paired with a confirmed email address and a gaming handle, they supply the raw material for targeted pretexting: answering security questions on unrelated platforms, or convincing a telecom or bank helpdesk agent that the caller is the account holder.

Nicknames are the volatile part. Gaming platforms encourage persistent, unique personas, and players often reuse one handle across Twitch, Discord, Twitter, and niche forums. A nickname from this breach can link a private or pseudonymous Capcom account to a public, searchable footprint. Once an attacker connects a CAPCOM ID email to a public streaming or social profile, they can collect relationships and behavioral patterns quickly. That kind of cross-platform linking underpins doxxing and targeted harassment.

Capcom has not said these 43 records were specifically targeted, and it has not reported downstream identity fraud against their owners. Even so, the smallest and most sensitive slice of a breach usually needs the most support per person.

Centralized gaming identity and the blast radius problem

A unified account system gives players one login across a publisher’s catalog, gives support teams one place to manage accounts, and lets the company apply security policy consistently. It also concentrates risk. When dozens of web services and online features depend on one identity provider, that provider becomes a high-value target with a very large blast radius.

Capcom said the breach did not affect players’ ability to access or play its games. If that holds, it suggests the authentication servers were separated from matchmaking and progression systems, though that is my inference and Capcom has not described its architecture. In a well-segmented design, compromising the identity database should not let an attacker alter in-game economies or match results.

Least privilege still has to hold across every integration. A mobile companion app that shows match history needs a narrowly scoped, read-only OAuth 2.0 token, with no ability to change credentials or pull deep profile attributes. Internal support tools should use role-based access control so a frontline agent cannot reset passwords or view sensitive metadata without a second approval. If an attacker can abuse an insecure API to enumerate users or trigger resets, database encryption and network segmentation do little. The investigation should look at how internal service-to-service calls and API gateways validated each request, as well as how the perimeter was crossed.

How this compares with Capcom’s 2020 ransomware attack

In November 2020, Capcom disclosed a ransomware attack by the Ragnar Locker group. The attackers got in through an old backup VPN device at Capcom’s North American subsidiary and exfiltrated corporate data, sales reports, and internal communications. That was a classic perimeter failure: unpatched legacy infrastructure and weak internal segmentation.

Capcom responded with endpoint detection and response tools, 24/7 security operations center monitoring, and stricter device management. The 2026 incident does not look like a continuation of that campaign, and nothing disclosed so far suggests those fixes failed. It looks more like the shift attackers have made toward public-facing customer identity platforms and API ecosystems, and away from corporate network perimeters.

A company can clean up legacy vulnerabilities and harden its internal network, yet stay exposed through customer-facing identity services that get less rigorous validation. Whether this incident came from a zero-day, a misconfigured cloud service, or ordinary secure coding failures in the CAPCOM ID endpoints will only be clear once the investigation reports.

APPI, GDPR, and CCPA exposure

Capcom reported the incident to the Osaka Prefectural Police and to Japan’s Personal Information Protection Commission (PPC). Under the 2022 amendments to the Act on the Protection of Personal Information (APPI), reporting is mandatory when a breach involves sensitive data, large-scale exposure, or signs of malicious intent. The PPC expects a preliminary report soon after the company becomes aware, followed by a final report covering root cause, scope, and remediation.

Because CAPCOM ID users are global, Capcom’s regulatory exposure does not stop at Japan’s borders. Depending on where affected players live, the breach may trigger notification duties under the EU’s GDPR, California’s CCPA, and other regional laws. Definitions of personal data differ, as do notification thresholds and deadlines. An email address plus a pseudonymous handle may be treated differently from a full name plus a date of birth, but IP addresses and login timestamps often bring a dataset within GDPR’s scope.

The incident also shows the tension in data minimization. Regulators want companies to collect and keep only what they need, while fraud detection and incident response depend on authentication logs, IP addresses, and behavioral metadata. Every retained log line is also a liability if the database is breached.

What gaming companies should fix after the CAPCOM ID breach

Detect anomalies by behavior

A rule that fires after ten password resets from one IP in an hour is easy to stay under with a distributed botnet or slow enumeration. Better baselines flag a password change from a region that does not match the user’s login history, or an API call sequence that mimics the web interface but lacks human timing.

Move to phishing-resistant authentication

TOTP codes and SMS still fall to real-time proxy phishing and SIM swapping. FIDO2, WebAuthn, and passkeys bind the credential to the domain and the device, so a stolen password or intercepted session token is far less useful to an attacker working from a remote server. For users who keep passwords, changing critical attributes, starting a reset, or linking a third-party service should require re-authentication, ideally through an out-of-band channel or a biometric check.

Rebuild account recovery

Reset tokens should be cryptographically secure, bound to the requester’s session, single use, and short lived. Rate limits and progressive delays on recovery requests blunt automated enumeration and credential stuffing. Resetting the passwords on the 196 affected accounts was the right containment step. Real remediation means finding the flaw that allowed the changes and removing it.

What CAPCOM ID users should do now

Expect phishing that looks accurate. Login timestamps, IP-derived details, and nicknames from this breach can make fake security alerts convincing. Ignore links in any unsolicited message about your Capcom account, open the official CAPCOM ID portal from a bookmark or your own search, and check your account there.

If you reused your CAPCOM ID password on any other service, change it on those services too. A reset on Capcom’s side does nothing for accounts elsewhere that share the same password. A password manager that generates a unique password for each service is the practical fix.

What we still don’t know

Capcom has not published the root cause, and it has not said whether the 196 password changes went through the public application, an internal administrative API, or the database directly. It has not confirmed whether the original passwords were compromised, and it has not said whether the 43 deeply profiled records were targeted. Those four answers will decide whether this was a single flaw in the CAPCOM ID account-management code or something broader.