
Capcom has confirmed a data breach affecting its CAPCOM ID membership service. The company says an unauthorized third party accessed 11,774,247 records worldwide, including email addresses and account-specific metadata such as creation time, last-login time, login counts, and the client IP address used at the last login.
The incident is significant even though Capcom says customer-set passwords and credit-card information were not confirmed as exposed. An email address combined with activity and network metadata gives attackers a stronger basis for targeted impersonation, account-recovery scams, and follow-on phishing.
Capcom detected suspicious activity on October 19, 2026, blocked the access, and opened an investigation. Its October 22 notice identified three affected groups:
| Information or action | Confirmed scope |
|---|---|
| Email address and system-specific account metadata | 11,774,247 records worldwide |
| Birth date, gender, country/region, and nickname | 43 records |
| Unauthorized CAPCOM ID password changes | 196 accounts |
Capcom said it had not confirmed the compromise of passwords originally set by customers. It reset the passwords for the 196 accounts where unauthorized changes were detected, and said credit-card information was not included in the affected data.
The company’s October 23 update added an important detail: attackers accessed the e-Capcom store pages of 19 of those 196 accounts. The affected Japanese records included names, telephone numbers, postal addresses, dates of birth, purchase history, customer-inquiry history, and saved address-book information. Capcom said credit-card data was still not affected.
The immediate unauthorized access may be contained, but the exposed data can remain useful to criminals. A message that knows a user has a CAPCOM ID, references a recent login, or includes plausible account and region details can look more credible than a generic scam.
That creates a second-stage risk for Capcom users and for organizations whose employees use the same email addresses elsewhere. Defenders should treat the incident as an identity and social-engineering problem, not only as a consumer-account event.
Capcom is contacting affected customers and warns that attackers may impersonate Capcom or related parties through email, text, phone calls, or other communications. The company specifically advises users not to open attachments or follow URLs in suspicious messages.
Do not use links in an unexpected breach notification. Open Capcom’s official site or support portal manually and verify the message through a known channel. Attackers can exploit the publicity around a real incident to send convincing fake support messages.
Capcom has not confirmed that customer-set passwords were leaked, but any password reused on another service should be changed there immediately. Use a unique password for CAPCOM ID and enable multi-factor authentication wherever the service supports it.
Look for password-reset messages, login alerts, unfamiliar devices, and changes to recovery details. Organizations should also warn help desks and security teams that Capcom-themed requests may be part of a targeted social engineering attempt.
Keep message headers, sender details, URLs, and screenshots. Do not forward suspicious links by clicking them. These artifacts can help an incident response team identify a campaign and warn other users.
Security teams should add CAPCOM ID-themed lures to awareness and detection coverage for the next several weeks. Useful signals include:
The goal is not to block Capcom-related mail indiscriminately. It is to make the context of the breach visible to the people who handle identity, email, and support workflows.
A breach does not need to expose passwords or payment cards to become a useful phishing asset. Email addresses, account history, IP metadata, and a small number of richer records can help attackers make fraudulent communications feel authentic at scale.
For users, the practical response is simple: verify Capcom communications through an independently opened channel, stop reusing passwords, and report suspicious messages. For organizations, the priority is to brief support and identity teams before the first convincing impersonation request arrives.
Written by
Research
A DevOps engineer and cybersecurity enthusiast with a passion for uncovering the latest in zero-day exploits, automation, and emerging tech. I write to share real-world insights from the trenches of IT and security, aiming to make complex topics more accessible and actionable. Whether I’m building tools, tracking threat actors, or experimenting with AI workflows, I’m always exploring new ways to stay one step ahead in today’s fast-moving digital landscape.
Get the latest cybersecurity insights delivered to your inbox.