Sources checked: . FailSafe Research.
An account breach has several possible impacts: disclosure, account modification and loss of access. Those categories deserve separate counts and separate tests.
Read the disclosure by data category
Capcom’s 22 October notice identifies 11,774,247 CAPCOM ID records with email addresses and account metadata exposed. It reports additional profile fields for 43 of those records and unauthorized password changes on 196 accounts, which it reset. It says customer-set passwords were not confirmed leaked and payment-card information was not included. The company detected and blocked the access on 19 October while investigating further.
These are different categories within the disclosed scope, not figures to add together as independent affected populations. The notice does not justify assigning an unannounced initial-access method.
Test reading and changing an account separately
For your own identity service, build an assessment around distinct capabilities: retrieve profile information, enumerate account existence, initiate recovery, change a password, add a login method and invalidate sessions. A role allowed to perform one should not inherit the others by accident.
Use multiple synthetic users and test each relationship through the deployed APIs as well as the interface. An invisible button is not authorization. Capture the identity presented, target account, expected policy and actual effect.
Recovery has to close existing access
When a password changes, determine what happens to existing sessions, refresh tokens, remembered devices and alternative authentication methods. Test whether an old session can still alter security settings after recovery. Agree the intended behavior before treating a test outcome as a defect.
Support workflows also need independent verification. Exposed metadata may help an impersonator sound credible. Avoid relying on knowledge of account history as the sole proof that a caller owns the account.
Make an account-security engagement actionable
FailSafe application and API penetration testing can cover authentication, role boundaries and account recovery with business impact attached to each finding. SWARM helps reproduce multi-step paths and connect them to remediation and retesting.
The deliverable should identify which account operation failed and how to verify its correction. A single score labeled “authentication secure” cannot replace those control-level results.
Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.
Questions & answers
Questions about this topic
Direct answers to common questions about this page.
No. Its notice distinguishes email and metadata exposure from unauthorized password changes on 196 accounts, and says customer-set passwords were not confirmed leaked.
No. Disclosure, unauthorized modification and confirmed takeover need separate evidence and should not be conflated.
Related Articles
Quest Diagnostics incident: test the patient-record access boundary
Quest’s October filing describes unauthorized Quanum LSM access and an ongoing scope review. Lessons for healthcare portal and API authorization....
DTU breach: identity systems need more than a login test
DTU’s October disclosure describes unauthorized access to its identity system. Lessons for privilege boundaries, historical records and security evidence....
Onamae Desktop Cloud breach: review the provider-to-guest boundary
GMO’s Onamae Desktop Cloud disclosures describe malicious programs on some servers and later data publication. Lessons for hosted workload security....
Put this guidance to work
Discuss a scoped FailSafe SWARM assessment with reproduced findings, engineering handoff and remediation retesting. Containment and forensic investigation remain separate workstreams.
Test the boundary that matters