El 3 de agosto, alguien empezó a leer bases de datos de producción ajenas. No entró por ninguna de esas empresas: entró por la herramienta de inteligencia de negocio que todas compartían, porque era la que guardaba las credenciales.
Un servidor de BI es el sitio donde una organización conecta sus bases de datos para poder consultarlas sin fricción. El precio de esa facilidad rara vez aparece en el análisis de riesgos: esa máquina termina custodiando las llaves de todo lo demás. El fallo que Metabase hizo público el 6 de agosto es la demostración de lo que ocurre cuando alguien las coge.
¿Qué ocurrió?
La secuencia pública, según el aviso de seguridad de Metabase y la cobertura de BleepingComputer, ocupa cuatro días.
- 3 de agosto: fecha de acceso más temprana confirmada por las víctimas en instancias de Metabase Cloud.
- 6 de agosto: Metabase identifica el fallo, parchea automáticamente las instancias de Metabase Cloud, publica el aviso y urge a los clientes autoalojados a actualizar. Ese mismo día notifica a los afectados.
- 7 y 8 de agosto: Framework y Tally publican sus notificaciones.
El fallo es una inyección SQL explotable sin autenticación previa contra la base de datos de la propia aplicación, con puntuación CVSS 10.0. Se explotó antes de que existiera corrección, así que es un zero-day en sentido estricto, y no tiene CVE asignado. Afecta a las versiones 1.58 y posteriores, incluidas las instalaciones autoalojadas.
¿Por qué un fallo en el BI acaba en los datos de todos tus clientes?
Porque el objetivo real no era Metabase. La cadena, descrita en términos conceptuales, es la siguiente: el atacante inyecta consultas contra la base de datos de la aplicación sin necesidad de credenciales, escala hasta permisos de administrador de la instancia y, con ese nivel, alcanza el almacén donde la herramienta guarda las credenciales de cada base de datos conectada. A partir de ahí ya no necesita ningún fallo más: se conecta como se conectaría el propio equipo de datos y consulta lo que esas credenciales permitan consultar. La exfiltración de datos ocurre, por tanto, a través de un canal autorizado.
Es el mismo patrón del abuso de OAuth contra Salesforce: el atacante entra con permisos legítimos heredados de una integración de confianza.
La pregunta útil hoy, por tanto, tiene poco que ver con si tu instancia estaba parcheada. Tiene que ver con qué alcance tenían las credenciales que esa instancia guardaba. Si el usuario de conexión era un administrador de la base con permiso de lectura sobre todo el esquema, el alcance del incidente es todo el esquema.
¿Qué revelan los dos casos confirmados?
Framework, el fabricante de portátiles modulares, notificó a todos sus clientes que un atacante accedió a nombres, direcciones de correo, teléfonos, direcciones postales e IP de inicio de sesión. Según la compañía, la información de pago no se vio afectada; rotó sus credenciales tras el aviso y no detectó cambios de acceso administrativo ni accesos a sistemas fuera de Metabase.
Tally, la plataforma de formularios, comunicó a sus usuarios que su entorno de analítica fue comprometido el 3 de agosto y que el atacante alcanzó direcciones de correo y contraseñas en forma de resumen criptográfico, sin llegar a los formularios ni a las respuestas enviadas por terceros.
La comparación entre ambos es instructiva. En Framework, el dato expuesto es de contacto y domicilio, material suficiente para montar campañas de suplantación creíbles contra toda una base de clientes. En Tally, la segmentación funcionó: la analítica veía cuentas, no contenido de formularios, y eso acotó el daño. Lo que marcó la diferencia fue qué se había conectado a la herramienta, y con qué permisos.
¿Por qué los controles habituales no lo vieron?
Hay cuatro razones, y ninguna es negligencia.
No había CVE. Los programas de gestión de vulnerabilidades alimentados solo con identificadores públicos y con el catálogo KEV no tenían nada que priorizar. La vigilancia tiene que incluir los avisos del propio fabricante, que es donde apareció este.
Era un servicio gestionado. En Metabase Cloud el cliente no parchea ni ve el sistema operativo, porque la superficie de ataque pertenece al proveedor. La única palanca del cliente estaba después, en qué credenciales había depositado y con qué permisos.
El tráfico era legítimo. Con las credenciales de conexión ya robadas, las consultas llegan a la base desde el origen habitual y con el usuario habitual. No hay malware que detectar ni proceso extraño en un servidor, solo una sesión autorizada haciendo preguntas.
El registro de la instancia estaba al alcance del atacante. Metabase advierte de que los registros del sistema que muestren el patrón de compromiso pueden haber sido manipulados, lo que remite a un principio conocido: la evidencia útil es la que se envía fuera del equipo afectado.
¿Cómo detectar el compromiso en tus registros?
Metabase publicó un indicador de compromiso concreto y fácil de buscar en los registros de acceso.
Patrón:POST /api/session/reset_password→ 400, seguido deGET /api/user/current→ 200 desde la misma sesión u origen. Trátalo como compromiso mientras no se demuestre lo contrario, no como una alerta más que triar.
La búsqueda no debería quedarse ahí. Revisa el historial de consultas de la instancia en busca de extracciones masivas o de consultas a tablas que ese usuario nunca toca; busca accesos a las bases conectadas fuera del horario del equipo de datos y desde direcciones distintas a las de la instancia; y comprueba si se crearon o modificaron cuentas de administrador y claves de API en esas fechas. Si tu SIEM recibe los registros de consulta de la base, la extracción anómala deja más rastro que la intrusión inicial.
¿Qué hacer ahora?
El orden importa, porque actualizar sin rotar deja al atacante dentro con credenciales válidas.
| Acción | Por qué | Prioridad |
|---|---|---|
| Actualizar a versión corregida (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5 o superior) | Cierra la vía de entrada. Cloud fue parcheado automáticamente por el proveedor | Inmediata (autoalojado) |
| Rotar las credenciales de TODAS las bases de datos conectadas | Es el activo que el atacante buscaba; el parche no invalida lo ya robado | Inmediata |
| Revocar todas las sesiones activas | Expulsa sesiones que el atacante pudiera mantener | Inmediata |
| Revisar cuentas de administrador y claves de API | Detecta persistencia creada durante el acceso | Alta |
| Buscar el patrón de compromiso e inspeccionar el historial de consultas | Determina si hubo acceso y qué se consultó | Alta |
| Evaluar el alcance de datos personales y el deber de notificación | Arranca los plazos del RGPD y, si aplica, de NIS2 | Alta, en paralelo |
Si el patrón de compromiso aparece, la rotación de credenciales deja de ser preventiva y pasa a ser contención de un incidente en curso.
Si la instancia resulta comprometida, el análisis del alcance no debería hacerse a ojo. Determinar qué consultó el atacante y durante cuánto tiempo es trabajo de forense digital y de un equipo de respuesta a incidentes con el histórico de registros a mano.
El dato que nunca debería haber estado ahí
La lección estructural está en qué datos ve tu herramienta de analítica.
Muchas de las preguntas que se le hacen a un BI se responden con agregados, cohortes y tendencias; el teléfono y la dirección postal rara vez son la respuesta. Aun así, lo habitual es conectarlo a la base de producción con un usuario de permisos amplios, porque es lo más rápido, y dejar que el analista decida después qué mira. Ese atajo convierte el fallo de un proveedor en una notificación a toda la base de clientes.
Las medidas que habrían acotado este incidente son poco vistosas y bien conocidas: usuarios de solo lectura limitados a vistas concretas en lugar de acceso al esquema completo; vistas que expongan columnas agregadas o seudonimizadas en vez de identificadores directos; separación entre la analítica y las tablas que guardan datos de contacto; y un inventario de qué fuentes están conectadas a qué herramienta, con responsable asignado. Es minimización de datos implementada en el esquema, no redactada en la política de privacidad.
Merece la pena revisar también la caducidad de esas credenciales de conexión, que casi nunca expiran. Son credenciales sin dueño asignado, con permisos de lectura sobre lo más sensible del negocio y sin nadie que las rote.
¿Hay que notificar si el fallo fue de tu proveedor?
Sí, y es la parte que más discusión genera cuando se revisa el reparto de responsabilidades. A efectos del RGPD, la empresa que decide para qué se tratan los datos de sus clientes es la responsable del tratamiento, y esa condición no se transfiere al proveedor de BI porque el fallo fuera suyo. Si hay riesgo para los derechos de los afectados, la notificación a la autoridad de control corresponde a la empresa, en un plazo de 72 horas desde que tiene conocimiento. Cuando el riesgo es alto, se añade además la comunicación a los propios afectados, que es el paso que dio Framework con sus clientes.
El proveedor actúa como encargado del tratamiento y su obligación es avisar al responsable sin dilación indebida, que es lo que ocurrió el 6 de agosto. Para entidades sujetas a NIS2 se suma su propio circuito de notificación de incidentes significativos, con alerta temprana en 24 horas, y la obligación de gestionar el riesgo de la cadena de suministro. En España la ley de transposición sigue pendiente; la obligación material, no.
En la práctica, esto se resuelve antes del incidente: contratos con plazos de notificación explícitos y una gestión del riesgo de terceros que registre qué proveedor trata qué dato y con qué acceso. Cuando llega el aviso, el plazo ya ha empezado a contar.
Conclusiones de este caso
Metabase parcheó su servicio gestionado, publicó el aviso con indicadores de compromiso y trabaja con una firma forense externa. Aun así, el problema no admite solución del lado del proveedor: el daño lo determinó el alcance de las credenciales que cada cliente le había confiado.
Esa es la asimetría del modelo SaaS. Puedes externalizar la operación de una herramienta, pero no la responsabilidad sobre los datos que le entregas. Al revisar integraciones de datos, la pregunta que rinde no es cuántas herramientas tienes conectadas, sino qué vería un atacante si mañana cayera cualquiera de ellas. Ese alcance es el que revisamos en Hard2bit como empresa de ciberseguridad, antes de que lo mida otro por su cuenta.
Fuentes y atribución: este artículo se basa en divulgaciones públicas disponibles el 9 de agosto de 2026 — el aviso de seguridad de Metabase y las notificaciones de Framework y Tally, recogidas por BleepingComputer, TechCrunch y The Hacker News. El alcance de los incidentes puede ampliarse a medida que avance la investigación forense en curso. La mención de estas empresas responde a su propia comunicación pública y no implica valoración alguna sobre su nivel de seguridad.
Aviso: este contenido tiene finalidad defensiva y divulgativa. Los indicadores y acciones descritos deben validarse contra el aviso oficial del fabricante y adaptarse a cada entorno antes de aplicarse en producción. No sustituye asesoramiento jurídico sobre obligaciones de notificación.
