23 millones de personas. 22.5 millones de registros. 11 millones más.
Esas son las cifras de ShopServe, Sourcenext y Burger King Japan, tres de las filtraciones que empresas japonesas han divulgado en las últimas semanas.
No son las únicas.
El 9 de octubre, legisladores japoneses se reunieron para tratar las filtraciones de datos que golpean a empresas de todo el país. Masaaki Taira, que dirige el grupo de ciberseguridad del Partido Liberal Democrático, calificó la situación de emergencia. Pidió una respuesta de todo el país, del Gobierno y de la ciudadanía en conjunto.
El consejo del Gobierno ese día fue simple: corregir rápido las vulnerabilidades web, revisar a los proveedores y vigilar quién accede a los datos más importantes.
Una semana después, JPCERT/CC, el equipo nacional de respuesta a incidentes de Japón, mostró cómo trabajaban los atacantes. Usaron IA para buscar debilidades conocidas y atacar API. Incluso estudiaron el código de aplicaciones móviles para encontrar más API que atacar.
Este número sigue esa historia de principio a fin.
En este número
🌡️ Nivel de amenaza: Alerta alta
⚡ Noticias cubre tres de las filtraciones: Sourcenext, Burger King Japan y Studio.
🔎 Análisis a fondo entra en ShopServe, donde tiendas que habían abandonado la plataforma años atrás seguían afectadas por la filtración.
🎣 ¿Es phishing?
🔬 Investigación técnica: Cómo el restablecimiento de contraseña de Metabase dio acceso de administrador a los atacantes (CVE-2026-72898)
🛠️ Herramienta de la semana es Blutter, que JPCERT encontró en el conjunto de herramientas de los atacantes. Úsela para ver qué revela su propia aplicación.
👏 Persona de la semana es Loren Kohnfelder, autor del libro Designing Secure Software
📅 Evento de la semana es CODE BLUE en Tokio, del 17 al 18 de noviembre, donde interviene Shusei Tomonaga, CTO de JPCERT/CC.
📚 Libro de la semana es Designing Secure Software, sobre cómo diseñar aplicaciones que sigan siendo seguras aunque los atacantes sepan exactamente cómo funcionan.
😅 El meme
❓ Una pregunta antes de despedirnos.
Vamos al grano.
🌡️ Nivel de amenaza
⚡ Noticias
Los atacantes abusaron de la API de miembros de Sourcenext y pusieron en riesgo 22.5 millones de registros
Sourcenext es una empresa japonesa de software que vende aplicaciones y software para PC a consumidores.
Del 9 al 13 de octubre, los atacantes abusaron de la API que Sourcenext utiliza para consultar información de miembros. La empresa indica 22,519,960 registros como potencialmente afectados.
Según el cliente, esos registros pueden incluir direcciones de correo electrónico, contraseñas, nombres, direcciones, números de teléfono, fechas de nacimiento y datos de la cuenta. Los datos de tarjetas no estaban almacenados en el sistema afectado.
Por qué importa: Los datos expuestos pueden incluir las contraseñas de los clientes. Eso es lo preocupante.
La mayoría de las personas usa la misma contraseña en más de un lugar. Así que, con su correo electrónico y su contraseña de Sourcenext, los atacantes pueden intentar iniciar sesión en su correo, en sus cuentas de compras e incluso en su cuenta de trabajo. Si la reutilizó, entran.
Por eso el aviso de Sourcenext pide a los clientes que cambien esa contraseña en cualquier otro sitio donde la hayan usado.
La aplicación de Burger King Japan filtró unos 11 millones de registros de miembros
Del 2 al 7 de octubre, los atacantes entraron en el sistema que gestiona las membresías de la aplicación de Burger King Japan. La empresa confirmó una fuga de unos 11.18 millones de registros: nombres, datos de contacto, fechas de nacimiento e información de membresía.
En ese sistema no se guardaban números de tarjeta y, hasta ahora, no hay indicios de que se hayan filtrado contraseñas. Cómo entraron los atacantes sigue bajo investigación.
Por qué importa: Como no se filtraron números de tarjeta, es fácil pensar que este caso es inofensivo. No lo es.
Con un nombre, un número de teléfono y una fecha de nacimiento, un estafador puede enviarle un mensaje haciéndose pasar por Burger King. Como conoce datos reales sobre usted, parece auténtico. Usted pulsa el enlace y una página falsa le pide su contraseña o su número de tarjeta.
Por eso Burger King advierte a los clientes de que estén atentos a correos, mensajes y llamadas sospechosos.
Los datos de Studio estaban cifrados. El atacante también llegó a las claves.
Una vulnerabilidad en Studio, un creador de sitios web japonés, permitió a un atacante entrar en su entorno de nube. Todos los clientes registrados están potencialmente afectados.
Lo que puede haberse expuesto: datos de las cuentas, contenido de los sitios web, respuestas de formularios y las claves de API que los clientes usaban para conectar Studio con otros servicios. Studio no ha confirmado que los datos se descargaran, pero responde como si así fuera.
Por qué importa: Studio es el caso que conviene leer con atención, porque tres cosas que suelen parecer seguras no resistieron:
Cifrado. Algunos datos estaban cifrados, pero el atacante también llegó a las claves para descifrarlos.
Eliminado. Las respuestas de formularios que estaban en la papelera pueden haberse expuesto también. Solo quedaron fuera las eliminadas de forma permanente antes del 30 de septiembre.
Corregido. Aplicar el parche a Studio no lo soluciona todo. Los clientes tuvieron que sustituir por su cuenta algunas de las claves de sus otros servicios.
Un creador de sitios web no guarda solo sitios web. Guarda las claves de todo aquello a lo que esos sitios se conectan.
🔎 Análisis a fondo
La filtración de ShopServe expuso a clientes de tiendas que ya habían abandonado la plataforma
En agosto de 2022, King Jim, la empresa japonesa de papelería, sacó su tienda en línea principal de ShopServe.
Cuatro años después, pedía disculpas a sus clientes por una filtración en ShopServe.
Era una de las 7,858 tiendas actuales y anteriores afectadas por esa filtración, que alcanzó a unos 23.36 millones de personas.
King Jim ya no usaba ShopServe. Pero los registros de las personas que habían comprado en ella entonces seguían allí. Cuando ShopServe sufrió la filtración, esos registros quedaron expuestos.
Por eso este análisis a fondo plantea una pregunta sencilla: cuando se abandona una plataforma, ¿qué ocurre con los datos de clientes que se dejan atrás?
Qué ocurrió en ShopServe
ShopServe es una plataforma de tiendas en línea gestionada por la empresa japonesa E Store. Miles de negocios la han utilizado para vender por internet.
Del 21 de mayo al 1 de agosto de 2026, los atacantes aprovecharon un fallo en una de sus aplicaciones para ejecutar sus propios programas y sacar información de su base de datos fuera del sistema. E Store no ha dicho cuál era el fallo.
E Store publicó su informe final el 16 de octubre. Resultaron afectadas unas 23.36 millones de personas, en 7,858 tiendas actuales y anteriores. A unos 2.1 millones de ellas se les expuso parte de los datos de la tarjeta, aunque no los números completos ni los códigos de seguridad.
Los atacantes no se llevaron solo datos de compradores. También obtuvieron las credenciales que las tiendas usan para gestionar sus negocios y las del programa de afiliados de E Store.
Y fíjese en las palabras «actuales y anteriores». Algunas de esas tiendas habían abandonado ShopServe mucho tiempo atrás y aun así resultaron afectadas por la filtración.
Dos tiendas que habían sacado su tienda principal de ShopServe y aun así sufrieron la filtración
King Jim, la tienda de papelería, se fue hace cuatro años.
El aviso de King Jim del 4 de septiembre confirmó que se expuso información de sus antiguos clientes. Su tienda en línea actual no resultó afectada.
Y no fue solo la tienda antigua. El aviso también abarcaba Office Online, otra tienda de King Jim que ya estaba cerrada. Esa tienda ya no existía, pero los datos de sus clientes seguían formando parte de la filtración.
Luego llegó lo difícil. King Jim dijo que no podía comprobar si algún cliente concreto estaba afectado, porque no tenía la información necesaria para hacerlo. Tuvo que remitir a los clientes a E Store con sus preguntas.
Así, King Jim pidió disculpas por una filtración en una plataforma que ya había abandonado y aun así no pudo responder a sus propios clientes.
Los registros de PFU se remontaban a 2008.
PFU, una empresa del grupo Ricoh que fabrica escáneres, sacó su tienda principal de ShopServe en octubre de 2025. Algunas páginas de venta independientes permanecieron en la plataforma hasta septiembre de 2026.
Los registros en riesgo se remontaban a diciembre de 2008: hasta 169,355 pedidos.
Lo que llama la atención es cuánto tardó PFU en saber que sus propios clientes estaban implicados:
2 de agosto: se informa a PFU de la filtración.
8 de septiembre: PFU consulta a E Store y descubre que los antiguos clientes de su tienda principal podrían estar afectados.
17 de septiembre: PFU recibe la confirmación de que los datos de sus antiguos clientes resultaron afectados.
18 de septiembre: PFU publica sus disculpas.
Pasaron más de seis semanas entre que supo de la filtración y que supo que sus propios clientes estaban incluidos.
Las tiendas seguían teniendo que responder ante sus clientes
La filtración ocurrió en ShopServe. Pero fueron King Jim y PFU quienes escribieron a sus clientes, pidieron disculpas y respondieron a las preguntas.
Así lo ven los clientes. No compraron en E Store. Compraron en King Jim o en PFU. Cuando sus datos se filtran, miran el nombre que conocen.
Abandonar la plataforma no cambió eso, porque los datos antiguos seguían allí. Nadie ha dicho por qué se conservaron ni si alguien pidió que se eliminaran.
Solo hemos leído los avisos de estas dos tiendas, de un total de 7,858. Pero cualquier tienda que dejó ShopServe mientras los datos de sus antiguos clientes se quedaban allí podría encontrarse en la misma situación.
Qué hacer al abandonar un proveedor
Pida la eliminación por escrito. Al abandonar una plataforma, pida al proveedor que elimine los datos de sus clientes y que confirme que lo ha hecho.
Sepa qué siguen conservando. Si tienen que conservar algunos registros, averigüe cuáles y durante cuánto tiempo.
Acuerde qué ocurre si sufren una filtración. Deben avisarle con rapidez e indicarle cuáles de sus clientes resultaron afectados, para no esperar seis semanas a averiguarlo.
Cambiar de plataforma es un paso. Lograr que se eliminen los datos de sus clientes es otro, y es fácil olvidarlo.
Fuentes: Informe final de E Store · Aviso de King Jim · Aviso de PFU
🎣 ¿Es phishing?
Un correo de «ShopServe Customer Support» dice que sus datos formaron parte de la filtración de ShopServe.
Conoce su nombre, su antigua dirección de entrega y los últimos cuatro dígitos de su tarjeta. Para ver qué se expuso, le pide que inicie sesión en un portal de revisión del incidente.
Examine con atención el mensaje y adónde lleva el botón.
¿Es phishing?
🔬 Investigación técnica
Cómo el restablecimiento de contraseña de Metabase dio acceso de administrador a los atacantes (CVE-2026-72898)
Cualquiera puede usar una página de restablecimiento de contraseña. Ese es el objetivo: si olvidó su contraseña, no puede iniciar sesión primero.
Por eso la página solo debería pedir dos cosas, el token de restablecimiento que llega por correo y una contraseña nueva, e ignorar cualquier otra cosa que se envíe.
La página de restablecimiento de Metabase no ignoraba el resto. Si un atacante enviaba un campo adicional, Metabase lo introducía directamente en una consulta a la base de datos. Y lo hacía antes de comprobar siquiera si el token de restablecimiento era válido.
Es CVE-2026-72898, una inyección SQL que funciona sin iniciar sesión. Afecta a Metabase, la herramienta de código abierto que muchas empresas usan para crear paneles sobre sus almacenes de datos.
Tiene una calificación de CVSS 10.0. Los atacantes la usaron antes de que existiera una corrección, primero contra el propio servicio en la nube de Metabase y después contra empresas que ejecutaban Metabase en sus propios servidores en todo el mundo.
Se relaciona con este número. JPCERT/CC publicó una alerta específica sobre este fallo el 14 de agosto. El 8 de octubre incluyó los ataques a Metabase como uno de los métodos detrás de la reciente oleada de filtraciones en organizaciones japonesas.
JPCERT no ha nombrado a las víctimas japonesas ni ha dicho cuántas fueron, y nada público vincula este fallo con la filtración de ShopServe de nuestro análisis a fondo. Lo que sí muestra es cómo una herramienta interna accesible desde internet puede llevar a los atacantes a los datos de clientes que hay detrás.
Qué es Metabase y por qué lo atacan
Metabase permite a las personas de toda una empresa crear paneles y ejecutar consultas sin escribir SQL. Para ello, se conecta a las bases de datos reales de la empresa (PostgreSQL, MySQL, Snowflake, BigQuery, Redshift y otras) y almacena las credenciales de esas conexiones.
Así que, por diseño, es un sistema que:
Guarda credenciales válidas de las bases de datos más importantes de la empresa.
Puede consultar y exportar datos de todas ellas.
Suele desplegarlo un equipo de datos y no el de seguridad, y a veces se deja accesible desde internet para que se pueda usar desde cualquier lugar.
Metabase guarda su propio estado (usuarios, sesiones, claves de API, ajustes y esos datos de conexión) en una base de datos de la aplicación interna. Esa base de datos interna es donde aterriza esta inyección.
El error: el endpoint de restablecimiento aceptaba campos adicionales
El endpoint de restablecimiento de Metabase, POST /api/session/reset_password, declaraba los dos campos que esperaba:
request-body :- [:map
[:token ms/NonBlankString]
[:password ms/ValidPassword]]Ese esquema comprueba que token y password estén presentes y sean válidos. No rechaza otros campos.
La biblioteca de esquemas de Metabase, Malli, trata los mapas como abiertos por defecto, de modo que cualquier clave adicional en el cuerpo JSON superaba la validación y se entregaba, junto con el token y la contraseña, al código de inicio de sesión compartido.
Ese código de inicio de sesión comenzaba así (de auth_identity/provider.clj en la versión 0.58.22):
(merge request (authenticate provider request))
...
(when-let [user-id (:user-id $)]
(t2/select-one [:model/User ...] :id user-id))Combina la solicitud con el resultado de la autenticación y luego busca al usuario por :user-id.
Cuando la autenticación tiene éxito, el resultado contiene el :user-id real y sobrescribe cualquier valor de la solicitud.
Cuando falla, por ejemplo porque el token de restablecimiento no es válido, el resultado no tiene :user-id. El merge de Clojure solo sobrescribe las claves presentes en ambos mapas, así que un user-id aportado por el atacante sobrevive a la combinación y el código busca a un usuario con él.
Ese es el primer problema: la búsqueda se ejecutaba incluso cuando la autenticación había fallado.
Cómo el campo adicional se convirtió en inyección SQL
Por sí solo, un user-id que sobrevive permitiría a un atacante elegir qué registro de usuario obtenía el código. Lo que lo convirtió en inyección SQL es la forma en que Metabase construye las consultas.
Metabase usa HoneySQL, una biblioteca que construye SQL a partir de estructuras de datos de Clojure. Normalmente los valores se envían como parámetros, lo que mantiene seguras las consultas. Pero HoneySQL también admite una forma :raw cuyo contenido pasa directamente al texto SQL, sin parametrizar. Como explica el análisis de Wiz, un objeto JSON enviado como user-id llega como un mapa de Clojure, y si ese mapa tiene una clave raw, HoneySQL lo trata como una directiva para insertar la cadena en la consulta tal cual.
Todo junto:
El atacante envía una solicitud de restablecimiento con cualquier token, una contraseña de apariencia válida y un campo user-id adicional que contiene un fragmento de SQL sin procesar.
La validación se supera, porque el esquema solo comprueba los campos que declara.
La comprobación del token falla, así que el resultado de la autenticación no tiene un user-id que sobrescriba el del atacante.
La búsqueda de usuario construye su cláusula WHERE id = ... con el fragmento del atacante y la ejecuta contra la base de datos de la aplicación.
La solicitud falla con un error 400 «Invalid reset token», pero para entonces el SQL inyectado ya se ha ejecutado contra la base de datos de la aplicación.
Aquí explicamos el error, no entregamos un exploit funcional. El payload exacto depende de la base de datos que respalde Metabase (H2, PostgreSQL, MySQL o MariaDB), y el código de prueba de concepto público está disponible desde el 10 de agosto.
Lo que obtiene el atacante: acceso de administrador y todas las bases de datos conectadas
La inyección se ejecuta contra el almacén interno de Metabase, no directamente contra los datos del cliente. Aun así, da mucho a un atacante, por lo que ese almacén interno contiene. El aviso del proveedor se titula «SQL injection using an unauthenticated endpoint leading to admin access», y Bishop Fox enumera lo que se deriva de ello:
Acceso completo de administrador a Metabase.
Cambio de los ajustes de la aplicación y lectura de los secretos disponibles para la aplicación en ejecución.
Consulta y exportación de datos de todas las bases de datos a las que Metabase está conectado, con los privilegios de Metabase.
Por eso el vector CVSS marca el alcance como modificado. El error está en Metabase, pero el daño llega a todas las bases de datos que puede consultar.
Incidentes reales lo confirman. Metabase confirmó la explotación activa, CISA añadió el fallo a su catálogo de vulnerabilidades explotadas conocidas el 11 de agosto, y empresas como Framework, Tally, n8n y ChecklyHQ divulgaron que se accedió a datos de clientes a través de sus instancias de Metabase.
Los datos notificados incluían nombres, direcciones de correo electrónico, números de teléfono, direcciones de facturación, hashes de contraseñas y tokens de API.
Cómo corrigió Metabase la vulnerabilidad
La corrección se publicó en 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 y 0.63.5, con las versiones Enterprise 1.x correspondientes. Metabase autoalojado en las líneas de versiones 58 a 63 anteriores a esas versiones está afectado, y Metabase Cloud recibió el parche antes del aviso público.
Al examinar el código de restablecimiento e inicio de sesión del código fuente actual de Metabase, el problema está ahora cerrado en varios puntos y no en uno solo:
El esquema del endpoint está cerrado. Ahora es [:map {:closed true} ...], por lo que se rechaza una solicitud con campos no declarados.
Solo se pasan los campos esperados. El handler llama a select-keys para reenviar :token y :password, y nada más.
Los datos de la solicitud no pueden aportar los campos de identidad. Antes de combinar, el código de inicio de sesión elimina de la solicitud todas las claves que debe establecer la autenticación, como :user-id, :user y :success?.
Sin búsqueda si no hay éxito. El usuario se resuelve solo cuando la autenticación tuvo éxito de verdad, y solo si user-id es un entero positivo. Cualquier otra cosa se registra y se rechaza.
Cualquiera de estas medidas habría detenido este exploit. Tener las cuatro hace menos probable que un error futuro en una capa se convierta en otro CVE.
Qué comprobar si ejecuta Metabase
Aplicar el parche responde a «¿sigo siendo vulnerable?». No responde a «¿ya me habían comprometido?».
Si /api/session/reset_password era accesible desde internet en una versión afectada, tanto el proveedor como JPCERT indican que se trate la instancia como posiblemente comprometida:
Busque el patrón de explotación. Un POST /api/session/reset_password que devuelve 400, seguido de un GET /api/user/current que devuelve 200. JPCERT afirma que esta secuencia sugiere con fuerza un compromiso. Wiz añade que las solicitudes de restablecimiento legítimas contienen solo token y password, por lo que cualquier cuerpo con una clave user-id es sospechoso.
Compruebe los indicadores que publicó JPCERT. Solicitudes entre principios de agosto y principios de septiembre de 2026 desde 213.163.202[.]171, 221.216.140[.]49 o 221.216.140[.]129, o con los user agents python-requests/2.33.1 o Metabase-GHSA-vwf4/2.0. JPCERT señala que esas IP pueden estar usándose de forma legítima a día de hoy.
Revoque y rote. Elimine todas las filas de la tabla core_session para cerrar todas las sesiones, quite las claves de API que nadie reconozca, revise las cuentas de administrador y rote las credenciales de todas las bases de datos conectadas.
Revise el lado de los datos. Compruebe la actividad y el historial de consultas de Metabase y los registros de su almacén de datos en busca de consultas o exportaciones que nadie del equipo ejecutó.
Si no puede actualizar de inmediato, bloquee /api/session/reset_password en el proxy inverso o en el firewall.
Lecciones para los desarrolladores
Valide lo que recibe, no solo lo que espera. Un esquema que comprueba los campos obligatorios pero acepta extras es un filtro con un agujero. En los endpoints sin autenticación, rechace los campos no declarados o pase solo los campos que necesita.
No deje que los datos de la solicitud compartan espacio de nombres con datos de confianza. Combinar la entrada del usuario en un mapa que también contiene el resultado de la autenticación significa que una clave ausente en un lado se convierte en entrada del atacante en el otro. Manténgalos separados o elimine primero de la entrada las claves de confianza.
Las rutas de fallo requieren tanto cuidado como las de éxito. Esta búsqueda se ejecutaba después de que la autenticación ya había fallado. El código que se ejecuta en la ruta de error sigue siendo accesible para cualquiera que pueda provocar el error, y en un endpoint de restablecimiento eso es todo el mundo.
Los constructores de consultas siguen exigiendo que conozca dónde está la vía de escape. HoneySQL parametriza los valores por defecto, pero su forma :raw no lo hace. Si datos no confiables pueden llegar a un constructor de consultas como una estructura y no como un escalar, compruebe si esa estructura puede expresar SQL sin procesar.
Trate las herramientas internas como expuestas a internet cuando lo están. La alerta de octubre de JPCERT señala en concreto las herramientas de BI y los sistemas de empleados: compruébelos con las mismas medidas que las aplicaciones de cara al público. Una herramienta de paneles con credenciales de almacén de datos almacenadas es uno de los sistemas más valiosos a los que puede llegar un atacante.
🛠️ Herramienta de la semana: Blutter
En un servidor que investigó, JPCERT/CC encontró archivos de aplicaciones Android junto a archivos vinculados a dos herramientas de ingeniería inversa: el descompilador JADX y Blutter.
Los atacantes hacían ingeniería inversa de aplicaciones para encontrar las API que había detrás y luego probaban esas API en busca de debilidades.
Blutter es la herramienta creada para aplicaciones Flutter.
Qué hace Blutter
Un descompilador como JADX no llega muy lejos con una aplicación Flutter, porque el código Dart se compila a código máquina nativo en libapp.so. Blutter está pensado para hacer ingeniería inversa de ese archivo. Ofrece:
El código de la aplicación en ensamblador, con los nombres de función recuperados.
Un volcado de los objetos Dart de la aplicación, donde aparecen direcciones de servidores y claves codificadas.
Una plantilla de script de Frida para hacer hooking de la aplicación en tiempo de ejecución.
Cómo usar Blutter con su propia aplicación
Ejecútelo con su propia aplicación o con una que esté autorizado a probar. Revise los objetos extraídos en busca de direcciones de servidores y claves codificadas, y compruebe a qué puede acceder cada clave.
Limitaciones
Solo Android ARM64 y versiones recientes de Dart. La compatibilidad con iOS no está terminada y las aplicaciones ofuscadas no son totalmente compatibles.
No es un descompilador completo. Se obtiene ensamblador y objetos, no código fuente.
La configuración requiere herramientas de compilación y puede que primero haya que compilar el runtime de Dart correspondiente.
La conclusión
Con herramientas como esta, cualquiera que descargue su aplicación puede deducir cómo se comunica con su servidor. Mantener la API dentro de la aplicación no la protege.
Lo que la protege es que el servidor compruebe, en cada solicitud, quién pregunta y qué se le permite ver.
👏 Persona de la semana: Loren Kohnfelder
En 1978, Loren Kohnfelder escribió su tesis de grado en el MIT, Towards a Practical Public-key Cryptosystem. En ella introdujo el certificado digital: un registro firmado que vincula una clave pública con un nombre. Los certificados que sustentan HTTPS hoy se basan en esa idea.
En Microsoft, él y Praerit Garg crearon STRIDE, una de las formas más extendidas de analizar las amenazas a un sistema. También dirigió el trabajo de seguridad de la plataforma .NET. En Google, trabajó en el equipo de seguridad, ayudó a fundar el equipo de privacidad y revisó los diseños de seguridad de grandes sistemas.
Ya jubilado, ha volcado esa experiencia en el Libro de la semana de este número.
Por más de cuatro décadas de trabajo para lograr sistemas seguros desde el diseño, Loren Kohnfelder es nuestra Persona de la semana.
📅 Evento de la semana
CODE BLUE 2026
CODE BLUE es una conferencia internacional de seguridad en Tokio. Investigadores de Japón, del resto de Asia, de Europa y de EE. UU. presentan su trabajo más reciente, junto con talleres, concursos y un track para ponentes menores de 25 años.
Tras un número sobre la oleada de filtraciones en Japón, es la siguiente parada natural. La mayoría de las charlas cuentan con interpretación japonés-inglés, por lo que no hace falta hablar japonés para seguirlas.
Una charla encaja de lleno con este número. Shusei Tomonaga, CTO de JPCERT/CC, y Yuki Yano, de su Grupo de Respuesta a Incidentes, presentan Quality Assurance for Incident Response in the Age of AI.
Tras una filtración, alguien redacta un informe de investigación. Pero ¿cómo se sabe que ese informe respalda realmente sus conclusiones?
En su charla describen cómo JPCERT/CC colaboró con 13 proveedores japoneses de respuesta a incidentes, CSIRT y equipos de SOC para redactar dos listas de verificación y un informe de ejemplo, y luego creó un agente LLM que revisa los informes con arreglo a ellas.
📍 Bellesalle Takadanobaba, Tokio, Japón 📅 17–18 de noviembre de 2026
📚 Libro de la semana
Designing Secure Software
Este número vuelve una y otra vez a un hecho: los atacantes averiguarán cómo funciona su sistema. JPCERT encontró atacantes que leían aplicaciones móviles para trazar el mapa de las API que había detrás.
Designing Secure Software: A Guide for Developers, de Loren Kohnfelder, nuestra Persona de la semana, parte de esa premisa. El libro trata de integrar la seguridad en el diseño de un sistema, no de añadirla al final.
Uno de sus patrones es Transparent Design: un sistema debe seguir siendo seguro aunque los atacantes sepan exactamente cómo funciona. Eso no significa publicar contraseñas ni claves. Esas siguen siendo secretas. Significa que el diseño en sí no debería depender de permanecer oculto.
😅 El meme
Si uno de sus antiguos proveedores sufriera mañana una filtración, ¿cuánto tardaría en saber si sus clientes resultaron afectados?
The Breach Brief,
Equipo de Ostorlab