El incidente de CAPCOM ID obliga a separar tres alcances distintos: 11.774.247 registros de correo e identificadores accesibles, 196 contraseñas modificadas sin autorización y 19 cuentas desde las que el intruso llegó a páginas de e-Capcom. Mezclar estas cifras convierte una investigación de identidad en una alarma imprecisa. La actualización del 23 de octubre de 2026 permite plantear una pregunta más útil: cuando alguien logra cambiar una contraseña, ¿a qué servicios conectados le abre la puerta esa nueva sesión?
Capcom confirmó acceso no autorizado a CAPCOM ID, cuenta unificada para varios servicios, y mantuvo operativos los juegos. No informó que las contraseñas originales establecidas por los clientes hubieran sido comprometidas ni que los datos de tarjetas formaran parte de lo afectado. Sí confirmó 196 cambios no autorizados de contraseña, restableció esas cuentas y después estableció que un tercero accedió a páginas de la tienda japonesa e-Capcom de 19 de ellas. El hecho posterior cambia la lectura empresarial: una credencial nueva puede trasladar el incidente desde el sistema de cuentas a un servicio relacionado que alberga más contexto personal.
Tres cifras, tres preguntas diferentes
El primer comunicado oficial, del 22 de octubre, cuantificó 11.774.247 registros de direcciones de correo e identificadores específicos del sistema afectados a escala mundial. Esos identificadores incluían fechas de creación y último inicio de sesión, número de accesos y dirección IP del último inicio. Dentro de ese universo, 43 registros incluían fecha de nacimiento, género, país o región y apodo. Las 196 contraseñas cambiadas sin permiso pertenecían también a ese universo, no eran 196 millones ni una muestra que permita extrapolar fraude a todos los registros.
El comunicado del 23 precisó que se habían visitado páginas de e-Capcom de 19 de las 196 cuentas. Para esas 19, Capcom identifica nombre, representación fonética japonesa, teléfono, código postal, domicilio, género, nacimiento, historial de compras, consultas a soporte y direcciones guardadas. El alcance es Japón para estos registros de tienda. La empresa afirma que no halló información comprometida derivada del cambio de contraseña en las otras cuentas y que no se incluyeron tarjetas. No equivale a demostrar que ningún dato pueda circular en mensajes de suplantación: la propia compañía advierte sobre ese riesgo.
El 19 de octubre detectó actividad sospechosa y confirmó el acceso; el 20 estableció un equipo de respuesta y el 21 informó a la policía de Osaka y a la comisión japonesa de protección de datos. La investigación del alcance de los cambios de contraseña se declaró completada el 23, aunque siguió la vigilancia de CAPCOM ID y servicios relacionados. Nada de esto publica el vector técnico preciso de entrada. Tampoco se puede afirmar a partir de las cifras que hubo acceso a e-Capcom en las 196 cuentas.
El alcance se estrecha; el tipo de dato cambia
Las cajas indican subconjuntos de registros, no tres sumas independientes ni probabilidad individual de fraude.
El salto que interesa a un equipo de identidad
El atractivo de una cuenta unificada es que reduce fricción al usuario. Su costo de riesgo es que varias aplicaciones confían en el mismo estado de identidad. CAPCOM ID se utiliza para diferentes servicios web y puede facilitar acceso a e-Capcom. El caso aporta una secuencia comprobada —cambio de contraseña en una cuenta y acceso posterior a páginas de tienda en un subconjunto—, pero no detalla cómo se logró cambiar la contraseña. Por ello no es correcto etiquetar este incidente como credential stuffing, explotación de un flujo de recuperación, abuso de una API o fallo de MFA sin prueba.
Para una empresa con portal de clientes, comercio y soporte, la pregunta no es únicamente cuántos correos fueron vistos. Es qué atributos aparecen después de una autenticación y qué capacidades hereda la sesión: pedidos, direcciones, cambios de perfil, exportaciones, tickets y métodos de recuperación. Un portal puede ser seguro en aislamiento y aun así confiar demasiado en una sesión que acaba de pasar por una modificación de credencial sospechosa.
Proponga al equipo un ejercicio con una identidad ficticia y autorización: altere su contraseña en un entorno de prueba; observe si todas las sesiones antiguas se invalidan; compruebe si la tienda exige nueva autenticación antes de mostrar datos históricos; pruebe el aviso al correo previo y la ventana para recuperar la cuenta. Si un correo de aviso llega después de que la sesión nueva ya ha consultado compras o direcciones, el control puede ser informativo sin ser preventivo. Estas son pruebas sugeridas por Insylux, no afirmaciones sobre la arquitectura de Capcom.
Qué cambiar en la arquitectura sin castigar a todos los usuarios
Para el titular afectado, Capcom indica que restableció las 196 cuentas y notificará a las personas alcanzadas. Quien reciba un mensaje debe llegar al sitio por una ruta conocida y no a través del enlace o adjunto de un supuesto correo de reparación. Si reutilizaba una contraseña, conviene reemplazarla en los demás servicios desde dispositivos confiables. Si se trata de uno de los 19 perfiles de tienda, debe revisar datos de contacto, direcciones, historial de compras y consultas, y documentar cualquier cambio no reconocido mediante el canal de soporte oficial. No hay motivo factual para ordenar a los más de once millones cambiar su contraseña «porque se filtró» cuando la fuente declara que no ha confirmado compromiso de las claves originales.
Para el operador de una plataforma, una modificación de credencial debería elevar temporalmente el riesgo de la sesión. Una opción es exigir una verificación independiente antes de consultar datos sensibles o de cambiar una dirección de entrega, y emitir alertas por canales ya registrados. Otra es revocar tokens de servicios conectados en el momento del cambio y registrar el evento con identidad, hora, origen, factor utilizado y resultado. Los controles se deben probar contra cuentas legítimas que recuperan acceso; demasiada fricción puede generar abandonos y nuevas llamadas de ingeniería social al soporte.
El sistema de soporte también merece atención. La persona que llama puede conocer su correo, último acceso o datos de pedido y usarlos para parecer titular legítimo. No convierta datos expuestos en preguntas de autenticación. Forme al equipo para verificar por un canal previamente registrado, limitar cambios de dirección o teléfono después de una recuperación reciente y escalar anomalías sin revelar más información. Una evaluación de Ingeniería Social puede probar esos guiones autorizados; Ethical Hacking verifica rutas entre cuenta, tienda y soporte; y Security GAP Assessment sitúa responsabilidades y evidencia de controles.
Tres puertas para impedir que un cambio de clave se convierta en consulta de datos
Alerta al canal previo y registro íntegro del evento.
Revocación de tokens heredados; nuevo factor ante riesgo.
Reautenticación para compras, direcciones y soporte.
La consecuencia que sigue al comunicado: suplantación contextual
Capcom advierte sobre correos, mensajes y llamadas que suplanten a la empresa. El riesgo es más convincente cuando el delincuente conoce hechos verosímiles: una dirección real, una compra anterior o el contexto de una recuperación de cuenta. Por eso la comunicación de incidentes debe ser específica sobre qué datos se confirmaron, cuáles no y cuál es el único canal para soporte. Un aviso genérico de «tenga cuidado con el phishing» deja al usuario sin criterio para distinguir una notificación legítima de un pretexto.
En Colombia, España, México o cualquier mercado con usuarios de una plataforma global, el dato relevante no es una extrapolación local de los 19 casos japoneses. Es comprobar si la organización propia centraliza identidad para portal, tienda y soporte, y si una modificación de credencial invalida toda la confianza derivada. Los equipos legales deben valorar las notificaciones de cada jurisdicción con el alcance real y sus contratos; una cifra mundial no describe por sí sola la distribución territorial.
Preguntas frecuentes que cambian decisiones
¿Se filtraron 11,7 millones de contraseñas? Capcom no confirmó compromiso de las contraseñas originales. La cifra corresponde a registros de correo e identificadores; sí hubo 196 cambios de contraseña sin autorización.
¿Los 196 titulares vieron datos de tienda comprometidos? La actualización del 23 identifica acceso a páginas de e-Capcom de 19 cuentas; en las demás no halló información comprometida derivada de los cambios.
¿Se afectaron tarjetas? La compañía afirma que la información de tarjetas no estaba incluida en el conjunto afectado. Eso no impide vigilar mensajes de suplantación y los cambios de perfil.
¿Es aplicable a un portal B2B? Sí como patrón de diseño: una cuenta que conecta aplicaciones exige revocación, reautenticación contextual y pruebas de las rutas secundarias, sin asumir que el mecanismo de intrusión de Capcom sea el mismo.
Fuentes y límites de la investigación
Capcom, comunicado original del 22 de octubre de 2026: volumen de registros, 196 cambios de contraseña, cronología y límites de la información. Capcom, actualización del 23 de octubre de 2026: 19 accesos a e-Capcom, categorías de datos y cierre de la investigación del alcance de esos cambios. Ambos son declaraciones de la empresa afectada; no son un informe forense externo ni explican el vector inicial. Las recomendaciones de arquitectura, soporte y prueba son inferencias de Insylux para sistemas propios autorizados.
Una prueba que merece presupuesto
Pida al responsable de identidad que demuestre, con una cuenta de prueba, qué ocurre en tienda, soporte y sesiones de aplicaciones conectadas durante los diez minutos posteriores a un cambio de contraseña sospechoso. Ese experimento identifica una frontera concreta de riesgo antes de necesitar una notificación masiva.
