Aumento de filtraciones de datos personales en Japón por ataques a API y Metabase

De julio a septiembre de 2026, las organizaciones japonesas se enfrentaron a un fuerte aumento de filtraciones de datos personales a través de sistemas web: según Macnica, en solo tres trimestres ya se han registrado 119 incidentes, mientras que en todo 2025 hubo 84, y casos individuales (Park24, Monogatari) llevan a la compromisión de decenas de millones de registros; JPCERT/CC vincula esta ola con un abuso masivo de API móviles e internas, así como con la explotación de la vulnerabilidad crítica CVE-2026-72898 en Metabase, por lo que los operadores de servicios web, aplicaciones móviles y sistemas de BI deben inventariar con urgencia las API accesibles desde internet y actualizar Metabase a las versiones mínimamente seguras.

Detalles técnicos de los incidentes

Magnitud y cronología

El análisis del centro de Macnica muestra que hasta el 6 de octubre de 2026 se hicieron públicos 119 incidentes en Japón en los que los datos se filtraron a través de sistemas web; al mismo tiempo:

• 62 incidentes en 2024;
• 84 en 2025;
• 119 ya en 2026, de los cuales 81 desde julio, lo que indica un fuerte repunte.

La serie no incluye ransomware ni otros ataques «clásicos»: se trata precisamente de la compromisión de las capas web y de API. En su aviso del 8 de octubre de 2026 (alerta oficial de JPCERT/CC), JPCERT/CC constata una avalancha de incidentes «uno tras otro» en torno a septiembre.

Casos destacados de gran escala:

• Park24 (Times Car): acceso no autorizado a los datos de unos 6,6 millones de cuentas del servicio de carsharing y, por separado, filtración de imágenes de documentos de identidad de aproximadamente 1,6 millones de usuarios.
• Monogatari (aplicación Yakiniku King): filtración de 10 788 963 registros del sistema de miembros.

La causa de estos incidentes aún se está investigando oficialmente, pero por su magnitud y perfil encajan en la serie descrita por Macnica.

Vectores principales de ataques contra API

JPCERT/CC destaca varios modelos recurrentes de abuso de interfaces API de aplicaciones móviles y web:

1. Análisis de la aplicación móvil y extracción de:
   • la lista de endpoints de API del backend;
   • claves y tokens de API incrustados en la aplicación.

   A continuación, el atacante construye solicitudes HTTP directas a esos endpoints, a veces de forma que el tráfico se asemeje al uso normal, lo que dificulta su detección.

2. Acceso a funciones «internas» del API, no presentadas en la interfaz de la aplicación:
   • cambio de los niveles de privilegios de un usuario;
   • creación de cuentas no autorizadas;
   • pruebas del comportamiento del servidor al modificar cabeceras, eliminar el token o enviar un marcador de autenticación dañado;
   • búsqueda de detalles de cuentas mediante NoSQL injection «a ciegas».
3. Reutilización de claves de API robadas, comprometidas en otros sistemas.

Errores típicos en el lado de los sistemas protegidos:

• los endpoints devuelven más datos de los necesarios para una operación concreta;
• el API ejecuta operaciones con privilegios excesivos;
• la funcionalidad para miembros está disponible a usuarios anónimos;
• errores en la lógica de autorización y en la gestión de sesiones.

Macnica subraya además que las claves secretas de API y las contraseñas de bases de datos integradas en la aplicación cliente o en el código del navegador se extraen fácilmente incluso de código minimizado u ofuscado, por lo que estas prácticas son inaceptables (análisis de Macnica).

Explotación de CVE-2026-72898 en Metabase

Un vector aparte son los ataques a Metabase, una popular herramienta de BI, a través de una SQL injection crítica CVE-2026-72898 con puntuación CVSS 10.0 (entrada de NVD para CVE-2026-72898). La vulnerabilidad:

• es explotable sin cuenta de usuario;
• permite realizar SQL injection en la propia base de datos de Metabase;
• permite obtener privilegios de administrador de Metabase;
• a partir de ahí, el atacante puede descargar las credenciales guardadas de las bases de datos conectadas y acceder a su contenido.

Metabase informó del incidente en su servicio en la nube el 6 de agosto de 2026 y publicó una actualización de seguridad (actualización del 6 de agosto). Más tarde, la empresa publicó una lista ampliada de versiones mínimamente seguras para las distintas ramas del producto (security release del 12 de agosto) y una advertencia adicional sobre varios problemas críticos (security advisory en GitHub).

Según Metabase, el indicador clave de explotación de CVE-2026-72898 es:

• en los logs del servidor se registra POST /api/session/reset_password con código de respuesta 400;
• a lo que sigue GET /api/user/current con código 200.

Una medida temporal para quienes no pueden actualizar de inmediato es bloquear el endpoint /api/session/reset_password en el nivel del servidor web o del firewall de aplicaciones. Metabase describe expresamente esto como una solución temporal, no como una solución completa.

IOC de JPCERT/CC y Macnica

JPCERT/CC publicó un conjunto de indicadores de compromiso (vigentes como referencia y no como «lista negra», ya que las direcciones podrían haberse reutilizado para tráfico legítimo).

Actividad sospechosa de API (alrededor de septiembre de 2026)

• IP: 3.112.252[.]14
• IP: 54.95.112[.]6
• IP: 69.10.51[.]162
• IP: 172.86.91[.]7
• IP: 210.149.87[.]120
• User-Agent: curl/7.88.1
• User-Agent: python-requests/2.34.2
• User-Agent: Mozilla/5.0 ... Chrome/126.0 Safari/537.36

Explotación de Metabase (principios de agosto – principios de septiembre de 2026)

• IP: 213.163.202[.]171
• IP: 221.216.140[.]49
• IP: 221.216.140[.]129
• User-Agent: python-requests/2.33.1
• User-Agent: Metabase-GHSA-vwf4/2.0

Macnica destaca por separado las IP 210.149.87[.]120 y 69.10.51[.]162 como prioritarias para su comprobación, subrayando que la presencia de accesos desde estas direcciones es solo un motivo para un análisis más profundo de los logs y no una prueba directa de ataque.

Contexto de las amenazas y geografía

Aunque JPCERT/CC y Macnica no vinculan la serie de filtraciones con un grupo concreto, se aprecia un estilo común: los atacantes «sondean» masivamente cualquier sistema web público donde pueda haber datos personales y aprovechan cualquier debilidad que encuentren en autenticación, autorización, configuración o vulnerabilidades conocidas.

La lista de sistemas afectados va mucho más allá de las tiendas online: servicios de membresía, sistemas empresariales, atención al cliente, catálogos de bibliotecas, sistemas de reserva de trenes turísticos. Macnica también encontró 99 incidentes similares en 13 países y regiones fuera de Japón (incluidos 30 en Corea del Sur, 11 en Francia y 8 en Polonia), lo que indica el carácter global del enfoque de los atacantes.

El uso de automatización (hasta la selección de vulnerabilidades mediante IA) aún no se ha confirmado: en los logs no hay indicios directos de dicho uso, pero el alcance y la intensidad del escaneo hacen poco probable un enfoque totalmente manual, lo que es una señal importante para revisar el abanico de escenarios que se evalúan en las auditorías de seguridad.

Evaluación del impacto para las organizaciones

Están expuestos al máximo riesgo:

• organizaciones con aplicaciones móviles de consumo masivo (banca, retail, transporte, entretenimiento);
• servicios con modelo de «cuenta + bonificaciones/suscripción», donde se almacenan datos de contacto, historial de pedidos, números de tarjetas de fidelidad;
• empresas que utilizan Metabase, especialmente cuando el panel y el API son accesibles directamente desde internet;
• estructuras en las que las plataformas de BI tienen acceso a bases de datos de producción con información personal.

Posibles consecuencias de la inacción:

• filtraciones masivas de datos personales (nombres, contactos, documentos, datos de comportamiento);
• sanciones regulatorias por parte de las comisiones de protección de datos (en Japón, la Comisión de Protección de la Información Personal, que ya ha publicado su propia alerta y directrices: alert PPC, guidance PPC);
• compromiso de la analítica de negocio y de las bases de datos de producción a través de Metabase como único punto de entrada;
• daño reputacional y aumento de costes por la notificación a los afectados y las demandas posteriores.

Recomendaciones prácticas de protección

1. Medidas inmediatas para propietarios de Metabase

1. Identificar todas las instancias de Metabase (on-premise y en la nube) accesibles desde internet.
2. Comparar las versiones actuales con las mínimamente seguras publicadas por Metabase (lista de versiones seguras) y actualizar de inmediato al menos a la versión recomendada.
3. Hasta la actualización, bloquear /api/session/reset_password desde el exterior como mitigación temporal del riesgo.
4. Revisar los logs para detectar la siguiente secuencia:
   • POST /api/session/reset_password → HTTP 400;
   • GET /api/user/current → HTTP 200.

   Si se detecta dicha cadena, se debe considerar el servidor como comprometido.

5. Para las instancias en las que el endpoint era accesible desde internet, tras la actualización realizar el ciclo completo de recuperación recomendado por Metabase:
   • anular todas las sesiones de usuario activas;
   • volver a comprobar y eliminar las claves de API sospechosas;
   • auditar las cuentas de administradores;
   • cambiar las contraseñas y claves de todas las bases de datos conectadas;
   • analizar los logs de los almacenes de datos en busca de consultas anómalas;
   • examinar el historial de consultas en Metabase para detectar extracciones inesperadas.

2. Refuerzo de API y backends móviles

Las recomendaciones de JPCERT/CC y OWASP API Security (OWASP API Security Top 10) marcan un mínimo básico de controles:

• limitación del número de solicitudes por unidad de tiempo (rate limiting), especialmente para:
  • autenticación e inicio de sesión;
  • restablecimiento de contraseña;
  • envío de SMS y notificaciones por correo;
  • búsqueda y otras funciones de alto consumo de recursos.
• autorización estricta en cada endpoint, incluidos los «no públicos»:
  • comprobación de permisos no solo para operaciones de usuario, sino también para operaciones administrativas;
  • comprobación por separado de los métodos HTTP permitidos.
• principio de privilegios mínimos:
  • limitación de los ámbitos de datos para cada clave y token;
  • rechazo de claves «universales» con todos los permisos.
• plazo de vida estricto para los tokens de API y posibilidad de revocación rápida en caso de filtración.
• prohibición de almacenar secretos (claves de API, contraseñas de bases de datos) en aplicaciones móviles y código frontend.
• inclusión de las funciones administrativas dentro del perímetro de las pruebas periódicas de vulnerabilidades.

3. Supervisión y análisis retrospectivo de logs

Durante el próximo mes tiene sentido realizar un análisis en profundidad de los registros de servidores web, gateways de API y bases de datos durante un periodo de al menos 30 días, prestando atención a:

• volumen anómalo de solicitudes de API desde una misma dirección IP;
• picos de respuestas 403, 404, 503 y otros errores;
• accesos a endpoints y archivos inexistentes;
• aumento significativo del número total de solicitudes con estado 200 (abuso de llamadas «legítimas»);
• uso de funciones administrativas desde direcciones IP atípicas;
• aumento de la carga sobre la base de datos y el pool de sesiones que coincida con anomalías en el tráfico;
• incremento del número de intentos de inicio de sesión.

La conclusión clave para las organizaciones afectadas y potencialmente vulnerables es la necesidad de una comprobación urgente de las versiones de Metabase y su aislamiento frente al acceso directo desde internet, la implantación simultánea de controles de acceso estrictos y limitaciones de frecuencia para todos los endpoints de API, así como un análisis retrospectivo de los logs de al menos un mes según los indicios mencionados, seguido de la reemisión de las claves y contraseñas comprometidas.