Capcom ID Breach: 11.77M Accounts Exposed, What Is Confirmed

Capcom says a third party gained unauthorized access to CAPCOM ID, its shared online account, exposing 11,774,247 email addresses with login metadata such as the IP address used at last login. Passwords on 196 accounts were changed and have been reset. No card data was involved. Users should expect phishing and turn on two factor authentication.

This post sets out what Capcom has confirmed, what it has not said, what the exposed fields allow an attacker to do, what CAPCOM ID users should do today, and what any team running a consumer account service can check this week. Capcom has said it identified the attack method but has not described it, so we do not guess at it. We are also clear about where Safeguard fits: for an account data breach like this one, our fit is indirect, and we say so.

What happened

On 22 October 2026, Capcom Co., Ltd. published a notice in Japanese and English titled, in its English version, "Notice and Apology Regarding Customer Information Affected Through Unauthorized Access". The Japanese original is titled 不正アクセスによるお客様情報漏えいのお詫びとお知らせ. Both are on Capcom's investor relations site and are the primary sources for everything below.

According to the notice, a third party accessed customer information connected to CAPCOM ID. CAPCOM ID is the common account Capcom uses for its web services and for online features in some of its games. Capcom detected signs of the access on 19 October, blocked it the same day, and confirmed that the access was unauthorized. It set up an internal response headquarters on 20 October and reported the matter to the police and to Japan's Personal Information Protection Commission (PPC) on 21 October.

Capcom says its emergency measures are complete and that it has identified and addressed the attack method. CAPCOM ID and the games that use it remain available, and Capcom says players can keep logging in and playing. Registered email addresses can still be used. Capcom says it will contact affected customers individually, in sequence.

Gaming and technology outlets reported the notice within hours, including Notebookcheck, TheGamer, DualShockers, Inven Global, PlayFront and iXBT Games. Each worked from Capcom's notice; none reported independent details about the attack method or the attacker.

Timeline

Capcom gives dates but not clock times for its own response, and it does not say when the unauthorized access began. Inven Global points out that the start date of the intrusion was not disclosed. The rows with times below are when coverage appeared, taken from each outlet's own timestamp, converted to UTC and Japan Standard Time (JST) where the source gives a time zone.

From detection to reports to the police and the PPC took two days on Capcom's account. The notice followed one day later.

What changed since first reports

The story is hours old at the time of writing, and the facts have not moved since Capcom published. What has varied is how outlets described those facts. Where secondary coverage goes beyond the notice, we follow Capcom.

• Which fields leaked for whom. TheGamer lists email addresses, IP addresses, dates of birth, gender, country or region and nicknames together. Capcom's notice limits date of birth, gender, country or region and nickname to 43 records. For the other records, the exposure is the email address and system identifiers.
• Password hashes. PlayFront says password hashes were not compromised, and iXBT Games says passwords were not accessed. Capcom's notice says something narrower: it has not confirmed any leak of passwords that customers set themselves. It does not mention hashes at all. Treat hash exposure as unknown, not as ruled out.
• The 196 accounts. DualShockers describes these as takeover attempts. Capcom describes them as unauthorized password changes. Either way, someone other than the owner set a new password on 196 accounts, and Capcom reset them.
• Who received the reports. The English notice and Inven Global name the Osaka Prefectural Police. The Japanese notice, as we read it, refers to the police and the PPC.

Technical details

Capcom has published counts and field names, not technical indicators. This section lists every concrete value in the notice, then what the notice leaves out.

Exposed data, by record count

All counts are as of 22 October 2026, from Capcom's notice. The 43 and 196 records are subsets of the 11,774,247, not additional records.

Capcom gives a worldwide total only. Inven Global notes there is no breakdown by country or region, so the share of users in any one market is unknown.

Affected and not affected, with current status

There are no software versions to patch here; the affected system is a hosted account service that Capcom runs. The equivalent of an affected and fixed table is what was touched and what Capcom says it has done about it.

What Capcom has not published

These gaps matter for anyone trying to judge their own risk.

• The attack method. Capcom says it identified and addressed it. It does not say whether the access came through an application flaw, reused credentials, a third party, an internal account or something else. Nothing in the notice supports any one of those over the others.
• When access began. Only the detection date, 19 October, is given.
• Whether password hashes were read. The notice speaks only of customer-set passwords not being confirmed as leaked.
• How the 196 password changes happened. The notice does not say whether they went through the normal password change or reset flow, or through some other path.
• Indicators of compromise. There are no attacker IP addresses, user agents, domains or file hashes in the notice. Capcom has not published phishing sender domains either. If you see lists of "Capcom breach IOCs" circulating, they did not come from the notice.
• A per-country breakdown.
• Financial impact. The notice makes no statement on earnings.

The notice itself

For readers who need to cite it precisely: the Japanese notice is issued by Capcom Co., Ltd., names President Haruhiro Tsujimoto, and lists the company as Tokyo Stock Exchange Prime, code 9697. The English version is at capcom.co.jp/ir/english/news/html/e261022.html and the Japanese original at capcom.co.jp/ir/news/html/261022.html. Both are dated 22 October 2026.

Official contact channels

Capcom has published no indicators, so the most useful defensive data in the notice is the list of genuine contact channels. Anything claiming to be Capcom support that does not match these is worth a second look.

Why login metadata is more useful to an attacker than it looks

An email address alone is a phishing target. An email address with account metadata is a better one, because it lets a sender write messages that look like they come from someone who knows the account.

• Account creation date and time lets a phishing email say "your account created on 14 March 2019" with the right date. Users tend to trust messages that contain details only the real service should know.
• Last login date and login count separate active players from dormant accounts. A scammer can aim at the accounts most likely to respond, or at dormant ones whose owners will not notice a takeover.
• IP address at last login gives an approximate location and the user's network provider. That can make a message's language, time zone and references fit the recipient, and it can help someone who calls a support desk pretending to be the account owner.
• Date of birth, gender and nickname for the 43 records add personal details that support desks sometimes use as weak identity checks.

None of this is unique to Capcom. It is why metadata that looks harmless in a database schema deserves the same care as profile fields.

How CAPCOM ID works, from Capcom's own help pages

Understanding the account model helps users decide what to check. Capcom's CAPCOM ID help pages describe the following.

• Users register with an email address and password, either on the CAPCOM ID portal or by scanning a code shown in a game. A verification email link expires after 24 hours if not completed.
• After registering, users can link a platform account: PlayStation, Xbox network, Steam or Epic Games, each through that platform's own sign in screen. Nintendo accounts are paired by entering a registration code that is valid for 10 minutes. Capcom notes that re-linking may be limited once an account is linked.
• CAPCOM ID supports two factor authentication. Capcom's support page says it asks for a code from an authenticator app on a smartphone or tablet, in addition to the ID and password. It names Google Authenticator and Microsoft Authenticator as recommended apps. It is set up, and cancelled, from the Account page.
• A forgotten password is reset through "Forgot your password?" on the log in page.

That last point is the reason two factor authentication matters here. If someone can change or reset your password, an authenticator code is the step that still stands between them and your account, provided the change flow itself asks for it.

History, kept separate

This is not Capcom's first security incident, and some coverage mentions the earlier one, so here are the facts from Capcom's own April 2021 report. In October 2020, attackers got into Capcom's network through an older backup VPN device at its North American subsidiary, moved to systems in the United States and Japan, and deployed ransomware on 1 November 2020. Capcom's final count of people whose data was confirmed compromised was 15,649, and it said no credit card data was involved. Afterward, Capcom added round the clock monitoring and endpoint detection, disposed of the old VPN device, and in January 2021 set up the Information Technology Security Oversight Committee with external experts.

That committee is the same body Capcom reported the CAPCOM ID incident to on 20 October 2026. Beyond that, nothing published links the two incidents, and we draw no connection between them.

Who is affected

What CAPCOM ID users should do now

1. Verify before you click. Capcom warns that the leaked information may be used in emails that impersonate Capcom or related parties, and asks customers not to open links or attachments in unexpected messages. If an email asks you to "verify" or "secure" your account, go to the CAPCOM ID site by typing the address yourself, or use a channel from the table above.

2. Turn on two factor authentication. On the CAPCOM ID Account page, set up an authenticator app. If you change phones later, cancel 2FA on the old device first, as Capcom's support page advises; otherwise you may be locked out.

3. Change reused passwords. Capcom has not confirmed any password leak. But if your CAPCOM ID password is used anywhere else, change it on those other sites now. That is the cheapest protection against any future credential stuffing using this data.

4. Check whether a password is already in public breach corpora. The free Pwned Passwords range API lets you check a password without sending it: you send only the first five characters of its SHA-1 hash, and compare the rest locally. On macOS (zsh or bash):

   read -rs PW
   HASH=$(printf '%s' "$PW" | shasum -a 1 | awk '{print toupper($1)}'); unset PW
   curl -s -H "Add-Padding: true" "https://api.pwnedpasswords.com/range/${HASH:0:5}" \
     | grep -i "^${HASH:5}:" | grep -v ':0' || echo "Not found in Pwned Passwords"
   

   On Linux, replace shasum -a 1 with sha1sum. The Add-Padding header pads the response with fake entries whose count is 0, which is why the command drops lines ending in :0. On Windows PowerShell:

   $sec = Read-Host -AsSecureString
   $plain = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($sec))
   $sha1 = [System.Security.Cryptography.SHA1]::Create()
   $hash = -join ($sha1.ComputeHash([Text.Encoding]::UTF8.GetBytes($plain)) | ForEach-Object { $_.ToString("X2") })
   Remove-Variable plain
   $resp = Invoke-RestMethod "https://api.pwnedpasswords.com/range/$($hash.Substring(0,5))"
   ($resp -split "`n") | Where-Object { $_ -like "$($hash.Substring(5)):*" }
   

   No output in PowerShell means the hash suffix was not found. A hit means the password has appeared in some breach, not necessarily this one, and should not be used anywhere.

5. Inspect suspicious emails properly. In most mail clients you can view the original message. Look at the From domain and the Authentication-Results header. On a saved message file:

   grep -iE '^(From|Reply-To|Return-Path|Authentication-Results):' suspicious.eml
   

   A dmarc=fail result, a lookalike domain, or a Reply-To that differs from the sender are reasons to delete the message. A dmarc=pass result is not proof of safety; it only means the sending domain is the one shown, and scammers register their own domains.

6. Review linked accounts and recent activity. Check which platform account is linked on the CAPCOM ID Account page, and check purchase history on each linked platform. If anything looks wrong, contact Capcom through the channels above and the platform's own support.

7. Expect phone and chat scams too. Account metadata makes impersonation of support staff easier in both directions. Capcom's genuine Japanese helpline is 0120-801-271; do not trust a number given in an unsolicited message.

Japan's APPI and reporting duties

Capcom is a Japanese company and reported to the PPC, Japan's data protection regulator. Under the Act on the Protection of Personal Information (APPI), as amended from 1 April 2022, a business must report a leak to the PPC and notify affected individuals when the leak risks harming individuals' rights and interests. The PPC's explainer lists four situations that meet that bar:

The PPC asks for a prompt report, which its explainer describes as roughly within three to five days. On Capcom's timeline, detection was 19 October and the PPC report was 21 October. Individuals must be told the summary of what happened, which items were affected and the cause, in a form they can understand, by letter or email for example. Where individual notice is difficult, the PPC allows substitute measures such as publishing a notice on the website and setting up an inquiry desk. Capcom has done both, and also says it will contact affected customers individually.

Capcom also serves customers in the Americas, Europe, the Middle East, Africa, Asia and Oceania. Its notice does not say whether it has notified regulators outside Japan, and we have not seen a statement either way.

How consumer account services usually get abused

Capcom has not said how this happened. This section is general background on the ways account services are commonly attacked, so that teams can test their own systems. It is not a description of this incident and does not suggest any of these applies to it.

• Credential stuffing. Attackers replay username and password pairs leaked from other sites. When the username is an email address, as it is for many consumer accounts, reused passwords across services do the rest. OWASP's guidance notes that email addresses make poor usernames for exactly this reason.
• Weak password change and reset flows. OWASP's API Security Top 10 lists changing an email, password or other sensitive setting without confirming the current password as a sign of broken authentication. Reset endpoints without per account rate limits, and reset tokens that are guessable or long lived, are common findings.
• Broken authorization on read endpoints. A profile or export endpoint that returns another user's record when given a different ID can leak a whole user table one request at a time.
• Excess access from staff, partners or tooling. Support consoles, analytics exports and administrative APIs often see more fields than any player feature needs.
• Vulnerable components. A framework or library in the account service with a known flaw can expose data to anyone who finds it.

Detection and remediation for teams running account services

These steps are for engineering and security teams running any account system, game or not. Table and column names are placeholders; adapt them to your schema. Use them on systems you own.

1. Baseline password changes and resets

A spike in password changes is one of the clearest signs of account takeover. With an auth event table in PostgreSQL:

SELECT date_trunc('hour', created_at) AS hour,
       count(*)                     AS password_changes,
       count(DISTINCT ip)           AS distinct_ips,
       count(DISTINCT account_id)   AS accounts
FROM auth_events
WHERE event_type IN ('password_change', 'password_reset_complete')
  AND created_at > now() - interval '30 days'
GROUP BY 1
ORDER BY 1;

Then look for single sources touching many accounts:

SELECT ip, count(DISTINCT account_id) AS accounts, min(created_at), max(created_at)
FROM auth_events
WHERE event_type IN ('password_change', 'password_reset_complete')
  AND created_at > now() - interval '7 days'
GROUP BY ip
HAVING count(DISTINCT account_id) > 3
ORDER BY accounts DESC;

Attackers rotate IP addresses, so also check for changes where the email address or recovery settings changed shortly before the password did, and for changes from a network the account has never used.

2. Find who is calling sensitive endpoints

From an nginx access log in the default combined format, where field 7 is the path and field 9 is the status:

awk '$7 ~ /^\/account\/password/ && $9 == 200 {print $1}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

From JSON application logs:

jq -r 'select(.path == "/api/v1/account/password" and .status == 200) | .client_ip' app.log \
  | sort | uniq -c | sort -rn | head -20

Compare the top sources against your hosting provider and proxy ranges. OWASP's credential stuffing guidance suggests treating hosting provider traffic differently from residential traffic, with challenges rather than blanket blocks.

3. Look for bulk reads of identity records

Data exposure at the scale of millions of rows usually shows up as unusual read volume somewhere: an API client, a database role, an export job. If you log record reads per client:

SELECT client_id, date_trunc('hour', created_at) AS hour, count(*) AS records_read
FROM profile_reads
WHERE created_at > now() - interval '14 days'
GROUP BY 1, 2
HAVING count(*) > 10000
ORDER BY records_read DESC;

At the database level, PostgreSQL's pg_stat_statements extension shows which statements return the most rows:

SELECT calls, rows, left(query, 120) AS query
FROM pg_stat_statements
ORDER BY rows DESC
LIMIT 20;

A query against the users table returning tens of millions of rows from an unexpected role deserves an explanation.

4. Rate limit password change and reset, per IP and per account

At the edge, nginx can cap requests per client address:

limit_req_zone $binary_remote_addr zone=pwchange:10m rate=5r/m;

server {
    location = /account/password {
        limit_req zone=pwchange burst=3 nodelay;
        limit_req_status 429;
        proxy_pass http://account_backend;
    }
}

Per IP limits alone are not enough. OWASP says IP blocking "should not be used as the sole or primary defense", because distributed attacks spread requests across many addresses. Add a per account counter in the application, keyed on the account ID, and a global alert when total reset volume moves above its baseline. OWASP's API guidance also says anti brute force limits on authentication endpoints should be stricter than general API rate limits, and should cover reset and recovery endpoints as well as login.

NIST SP 800-63B sets an upper bound for verifiers: no more than 100 consecutive failed attempts on a single account before the authenticator is disabled. Lower limits are allowed.

5. Require the current password and a second factor to change a password

A password change made from inside a logged in session should ask for the current password, and for a 2FA code when the user has enabled it. OWASP's API Security Top 10 calls for re-authentication before sensitive operations such as changing an email address or a 2FA phone number. A stolen session cookie should not be enough to take over an account permanently.

A quick test against your own staging environment, using a session token for a test account:

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://staging.example.com/api/v1/account/password \
  -H "Authorization: Bearer $TEST_SESSION" -H 'Content-Type: application/json' \
  -d '{"new_password":"correct-horse-battery-staple-2026"}'

If this returns 200 without a current_password field, the endpoint accepts password changes on session alone. Write that as an automated test that expects a 400 or 403, and run it in CI.

6. Notify users and invalidate sessions on every password change

OWASP's forgot password guidance says to email the user when a password is reset, without including the password, not to log the user in automatically, and to invalidate existing sessions. After a suspected compromise, it adds: do not rely only on recently changed recovery details, and notify every registered address. NIST SP 800-63B requires notifications for account recovery events and says they must include clear instructions and contact details in case the recipient did not make the change.

A simple pattern for session invalidation is a version counter on the user record, checked on every request:

UPDATE users
SET session_version = session_version + 1,
    password_changed_at = now()
WHERE id = $1;

Sessions issued with an older version number are rejected. Pair it with a notification to the address on file before the change, so an attacker who also changed the email address cannot suppress the alert.

7. Check new passwords against known breached passwords

NIST SP 800-63B requires that when a password is set or changed, it is compared against a blocklist of commonly used, expected or compromised passwords, and that the whole password is compared, not substrings. It also sets a minimum length of 15 characters for passwords used as a single factor, and 8 where the password is only one part of multi factor authentication. Your service can call the same Pwned Passwords range endpoint shown above from the server side, or host a local copy of the hash list.

8. Keep less login telemetry next to identity

The CAPCOM ID notice lists last login IP, last login time and login count in the same set of records as email addresses. Many services store these together because it is convenient. Ask whether every field needs to sit in the identity record, and for how long.

Two practical options. Drop old IP addresses on a schedule:

UPDATE login_metadata
SET last_login_ip = NULL
WHERE last_login_at < now() - interval '90 days';

Or store a truncated network instead of the full address when you only need rough location:

UPDATE login_metadata
SET last_login_net = network(set_masklen(last_login_ip, 24)),
    last_login_ip  = NULL
WHERE family(last_login_ip) = 4;

That keeps 203.0.113.0/24 rather than 203.0.113.45. Move full fidelity security logs to a separate store with its own access controls and retention, readable by the security team, not by every service that reads profiles.

9. Separate stores by sensitivity

Keep birth dates, addresses and similar fields in a separate table or service with narrower access than email and display name. In the CAPCOM ID notice, extra profile fields were exposed for 43 records out of more than 11 million. Whatever the reason in that case, separating sensitive fields is the pattern that keeps such numbers small.

10. Protect your sending domain

After any breach, impersonation emails follow. Check that your domains publish SPF and a DMARC policy that rejects spoofed mail:

dig +short TXT _dmarc.example.com
dig +short TXT example.com | grep -i spf

A DMARC record with p=reject stops direct spoofing of your exact domain at receivers that enforce it. It does nothing about lookalike domains, so also tell users which domains you send from, and what you will never ask for by email.

What would have helped

The cause of this incident is not public, so none of this is a judgement about Capcom or a statement about what it did or did not have in place. It is what any team running a large consumer account service can put in place so that a breach is smaller, found sooner and easier to explain.

Practices any team can use

• Step up verification for sensitive changes. Require the current password and a 2FA code for password, email and 2FA changes, and stricter rate limits on those endpoints than on the rest of the API.
• Alert on volume and on patterns. Baseline password changes, resets and record reads per hour. Alert on spikes, on single sources touching many accounts, and on bulk reads by unexpected clients or roles.
• Store less, and store it apart. Keep login telemetry out of the identity record, truncate or expire IP addresses, and keep sensitive profile fields in a separate store.
• Test authentication and authorization in CI. Every endpoint that changes credentials or returns user records needs tests that try the wrong user, the wrong session and the missing current password.
• Know your components. Keep an SBOM for each service in the account path, so that when a framework or library flaw is published you can find and rebuild affected services the same day.
• Rehearse the first 72 hours. Detection, containment, regulator reporting and customer notice all happened within three days in this case. Teams that have rehearsed can match that pace without improvising.

Zero-Day Discovery and Gold

Two Safeguard capabilities are relevant only to the component part of the problem, and we want to be clear about their limits here.

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in two modes, an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not examine your own account logic, your rate limits or your password change flow, and there is no public indication that a package flaw played any part in this incident. We make no claim that Zero-Day Discovery found, or could have found, anything related to it.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service with hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

The habit both support is pulling patched, signed components from a curated source and rebuilding quickly when a fix lands. For an account service, that shrinks the time in which a known flaw in the web framework or authentication library can be used.

Where Safeguard fits

For an account data breach, Safeguard's fit is indirect. It helps with the software that runs an account service, not with detecting or stopping someone misusing that service in production.

What it does help with:

• Component inventory and vulnerability matching. SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, with results as JSON under ./output), matched against vulnerability databases, with reachability analysis to show which findings sit on code paths the service calls. The platform shows which projects contain a given component and version.
• Dynamic testing of your own endpoints. Safeguard's first-party DAST runs scoped tests against targets you have verified you own, such as a staging copy of your login and password reset endpoints. Treat it as one input alongside the authorization and rate limit tests above.
• Policies, gates and fix pull requests. Policies and gates are evaluated in the platform, and autonomous remediation opens fix PRs for dependency upgrades; it ships off by default.
• Doing the work with approval. The Safeguard CLI's assistant edits code and runs commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict, and safeguard exec runs it in CI. You could ask it to add the session invalidation change and the current password test from step 5, and approve each edit. Desktop and phone apps can send work to a computer running the CLI and approve each command.

What it does not do: Safeguard does not watch production authentication traffic, detect credential stuffing as it happens, rate limit your API, decide whether your authorization logic is correct, publish indicators for this incident, file a PPC report or stop phishing aimed at your users. Capcom has not disclosed the cause, so we cannot say whether any tool would have changed the outcome, and we do not claim Safeguard would have prevented it.

Common mistakes and troubleshooting

• Reading "passwords not leaked" as "hashes safe". The notice says no leak of customer-set passwords is confirmed. It is silent on hashes. Advise users to change reused passwords regardless.
• Rate limiting by IP only. Distributed attacks use thousands of addresses. Add per account limits and global volume alerts.
• Notifying only the current email address. If the attacker changed the email first, the alert goes to them. Notify the previous address too.
• Changing the password but keeping sessions. A reset that leaves old sessions valid does not evict someone already logged in. Invalidate them.
• Over-locking accounts. OWASP warns that locking accounts in response to forgotten password requests lets attackers lock out real users. Challenge or slow down instead.
• Logging full IP addresses forever. Logs become a second copy of the data you meant to protect. Set retention and truncate where you can.
• Sharing unverified IOC lists. Capcom has not published any. Lists circulating on social media did not come from the notice.
• Breaking 2FA when changing phones. Capcom's support page says to cancel 2FA on the old device before setting it up on the new one, or you may be unable to log in.

Open questions

• How did the third party gain access, and when did it begin? Capcom says it has identified the method but has not described it.
• Were password hashes accessed? The notice addresses only customer-set passwords.
• How were the 196 passwords changed: through the normal change or reset flow, or another path?
• Were linked platform accounts affected in any way? The notice does not mention them.
• How are the 11,774,247 records spread across countries, and has Capcom notified regulators outside Japan?
• Will Capcom publish a technical follow up, as it did with its April 2021 report on the 2020 incident?

FAQ

What happened to CAPCOM ID?

Capcom says a third party gained unauthorized access to customer information connected to CAPCOM ID, its shared account for web services and some online games. It detected the access on 19 October 2026, blocked it the same day, and published a notice on 22 October.

How many accounts were affected?

Capcom gives 11,774,247 records worldwide with email addresses and system identifiers. Of those, 43 also had date of birth, gender, country or region and nickname exposed, and 196 had their passwords changed by a third party.

Was my password or credit card exposed?

Capcom says credit card information was not included. It has not confirmed any leak of passwords customers set themselves, but it does not say whether password hashes were accessed. If you used your CAPCOM ID password anywhere else, change it there.

How did the attackers get in?

Capcom has not said. It says it identified the attack method and addressed it, without details. Reports that name a specific method are not based on the notice.

Can I still use CAPCOM ID and play games?

Yes. Capcom says CAPCOM ID and the games that use it remain available and that gameplay is not affected. Registered email addresses can still be used.

Will Capcom contact me?

Capcom says it will contact affected customers individually, in sequence. Treat any message carefully, and verify it through a channel you look up yourself, such as the CAPCOM ID site or the contacts listed in Capcom's notice.

Should I turn on two factor authentication?

Yes. CAPCOM ID supports 2FA with an authenticator app, set up from the Account page. Capcom recommends Google Authenticator or Microsoft Authenticator.

Has Capcom told regulators?

Capcom says it reported to the police and to Japan's Personal Information Protection Commission on 21 October, and to its external Information Technology Security Oversight Committee on 20 October. It has not said whether it notified regulators outside Japan.

Is this related to Capcom's 2020 ransomware attack?

Nothing published connects them. The 2020 incident started through an older backup VPN device at Capcom's US subsidiary, according to Capcom's April 2021 report. The 2026 notice does not describe how access was gained.

Would Safeguard have prevented this?

We do not claim so. The cause is undisclosed, and Safeguard does not monitor production authentication traffic or detect account takeover. It helps teams keep the components behind an account service patched, test endpoints they own, and make code fixes with approval.

Fix it without waiting for upstream

The CAPCOM ID incident is an account data breach, not a known vulnerable package, so this section applies to the software underneath any account service rather than to this incident. When the next framework or authentication library flaw lands in your login path, these are the ways to close the gap fast.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Capcom or CAPCOM ID. Each is a real Safeguard session, and each intro says how the same flow applies to a team running an account service.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For an account service, you would run /scan . in the backend repository, ask the assistant to upgrade a vulnerable framework or auth library and to add the "password change requires current password" test from step 5, and approve each command as it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For an account team, you would pick the auth service folder, ask for the session invalidation change and the per account rate limit, and approve or deny each edit yourself.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. During a breach review, a security lead could ask Claude which projects in the account path carry a given component and version, using only the read tools they have allowed.

Click through it at your own pace, or open it full screen.

To try it on your own services, download Safeguard and follow the CLI docs. For a related Japanese incident, read our post on IDCF Cloud ransomware and third-party risk. For the wider month, see October 2026 security incidents and what would have helped, and for fast scoping with SBOMs, finding affected products fast. For how the CLI assistant works, see the Safeguard CLI as a security aware coding assistant.

Quick check

Sources

• Capcom: Notice and Apology Regarding Customer Information Affected Through Unauthorized Access (22 Oct 2026, English)
• Capcom: 不正アクセスによるお客様情報漏えいのお詫びとお知らせ (22 Oct 2026, Japanese original)
• Capcom: 4th Update Regarding Data Security Incident Due to Unauthorized Access: Investigation Results (13 Apr 2021)
• CAPCOM ID: Support and FAQ
• CAPCOM ID: Registration guide
• Personal Information Protection Commission: Mandatory leak reporting and notification to individuals (Japanese)
• NIST SP 800-63B: Digital Identity Guidelines, Authentication and Authenticator Management
• OWASP Credential Stuffing Prevention Cheat Sheet
• OWASP Forgot Password Cheat Sheet
• OWASP API Security Top 10 2023: API2 Broken Authentication
• Have I Been Pwned: API v3, Pwned Passwords range endpoint
• Notebookcheck: Capcom confirms major data breach affecting more than 11.7 million Capcom ID accounts
• Inven Global: Capcom cyberattack exposes 11.77 million CAPCOM ID records
• TheGamer: Capcom customer breach, 11 million records
• DualShockers: Capcom's data breach hit 11.7 million accounts
• PlayFront: Capcom reports security incident affecting over 11 million Capcom IDs
• iXBT Games: Capcom ID breach, data of 11 million accounts

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.