Metabase Zero-Day (CVSS 10.0) — Un Fallo de Inyección SQL sin Autenticación Expone a Framework, Tally y LexisNexis

El 6 de agosto de 2026, Metabase reveló que una vulnerabilidad crítica de inyección SQL sin autenticación —con CVSSv3.1 de 10.0 y sin identificador CVE asignado hasta la fecha de esta publicación— fue explotada activamente contra su plataforma Metabase Cloud desde al menos el 3 de agosto. El fallo, ubicado en el endpoint público de restablecimiento de contraseña, permite a un atacante remoto obtener acceso de administrador sobre la instancia y robar las credenciales de todas las bases de datos conectadas. El fabricante de laptops Framework, la plataforma de formularios Tally y el proveedor de datos legales LexisNexis ya confirmaron impacto, y el incidente se suma a un patrón de al menos cuatro vulnerabilidades críticas relacionadas con la capa de credenciales y conexión a bases de datos de Metabase durante 2026.

Contexto: ¿Qué ocurrió?

Metabase es una plataforma de código abierto de inteligencia de negocios (BI) y visualización de datos que permite a las organizaciones conectar sus bases de datos y convertir esa información en dashboards, reportes y consultas sin necesidad de escribir SQL directamente. Esa función —conectarse a las bases de datos de producción de una organización y almacenar las credenciales necesarias para hacerlo— es exactamente lo que convierte a cualquier vulnerabilidad crítica en Metabase en un problema que trasciende a la propia herramienta.

El CEO de Metabase, Sameer Al-Sakran, confirmó en una publicación de blog que la compañía identificó que su servicio administrado Metabase Cloud fue atacado mediante una vulnerabilidad de tipo “0-day” desconocida hasta ese momento, afectando a las versiones 1.58 en adelante. Metabase bloqueó de inmediato los endpoints utilizados en el ataque, identificó y parchó la vulnerabilidad, notificó a las fuerzas del orden y contrató a una firma forense externa para investigar el incidente.

El aviso de seguridad técnico, publicado en GitHub bajo el identificador GHSA-vwf4-m7j8-wcjf, califica la falla como Crítica, con un puntaje CVSS v3.1 de 10.0 —la severidad máxima posible— y confirma explotación activa confirmada por el propio fabricante. Al momento de esta publicación, la vulnerabilidad no cuenta con un identificador CVE asignado.

“Identificamos recientemente que Metabase Cloud fue atacado por alguien que utilizó una vulnerabilidad de seguridad desconocida (‘0-day’) en las versiones 1.58 y superiores”, declaró Metabase en su aviso oficial.

Los clientes de Metabase Cloud ya fueron actualizados automáticamente y no requieren acción adicional. Las instalaciones autogestionadas (self-hosted), en cambio, permanecen potencialmente vulnerables hasta que sus administradores apliquen el parche manualmente.

El Problema Técnico: Inyección SQL en el Endpoint de Restablecimiento de Contraseña

La vulnerabilidad reside en el endpoint público POST /api/session/reset_password, accesible sin autenticación por diseño —ya que su función legítima es permitir que cualquier usuario solicite el restablecimiento de su contraseña—. El fallo permite a un atacante remoto inyectar sentencias SQL arbitrarias directamente en la base de datos de aplicación de Metabase a través de ese endpoint, sin necesidad de poseer credenciales previas ni interacción del usuario.

El vector CVSS publicado por Metabase —AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H— describe con precisión la severidad del fallo: explotable de forma remota por red (Network), con complejidad de ataque baja, sin privilegios previos requeridos, sin interacción del usuario, con cambio de alcance (Scope: Changed) y con impacto alto en confidencialidad, integridad y disponibilidad. La combinación resulta en el puntaje máximo de 10.0.

Una vez lograda la inyección, el atacante puede manipular directamente los registros de la base de datos de aplicación para promoverse a sí mismo a una cuenta de administrador, obteniendo control total sobre la instancia. Desde esa posición privilegiada, según el propio aviso de Metabase, el atacante puede:

Alterar la configuración de la aplicación.
Robar las credenciales almacenadas de todas las bases de datos conectadas a la instancia.
Leer cualquier dato accesible a través de esas conexiones.
Exportar los datos a voluntad.

Este es precisamente el “peor escenario” para una herramienta de BI: al centralizar credenciales de múltiples fuentes de datos para facilitar consultas y dashboards, un compromiso de la capa de aplicación se traduce directamente en un compromiso de todo lo que esa aplicación tiene permiso de leer.

Víctimas Confirmadas: Framework, Tally y LexisNexis

Framework, el fabricante de laptops reparables conocido por su base de usuarios técnicamente exigente, confirmó a sus clientes que su instancia de Metabase fue vulnerable al zero-day y fue accedida por el atacante el 3 de agosto de 2026. Metabase notificó a Framework de la brecha el 6 de agosto. Según la notificación de Framework, los datos accedidos incluyen nombres completos, direcciones de correo electrónico, direcciones IP de inicio de sesión, direcciones de facturación y envío, números de teléfono y nombre de la empresa. Para clientes de Framework for Business, los datos comprometidos también pudieron incluir nombre de empresa, teléfono, número de VAT/EIN y correo de facturación. La compañía precisó que no se accedió a información de pedidos ni de pago.

Tally, la popular plataforma de creación de formularios en línea, notificó a sus usuarios que su entorno de analítica basado en Metabase fue comprometido también el 3 de agosto de 2026. Según su comunicación, los atacantes accedieron a direcciones de correo electrónico y contraseñas almacenadas como hash criptográfico —no reversible— pero no llegaron a los formularios ni a las respuestas enviadas por los usuarios, que se almacenan en un sistema separado.

LexisNexis, el proveedor de datos legales y analítica de riesgo, envió a sus clientes una notificación sobre una interrupción de servicio que afectó a los productos Diligence, Metabase API y Newsdesk. La compañía señaló que identificó actividad inusual en servidores alojados y administrados por un proveedor externo y tomó la decisión de desconectarse de esos sistemas de forma inmediata para contener el problema. LexisNexis no confirmó explícitamente que el incidente esté vinculado a la vulnerabilidad de Metabase, aunque sí reconoció que su Metabase API se vio afectada. Al momento de esta publicación no está claro si se expusieron datos de clientes; la compañía trabaja con una firma forense externa para investigar el alcance del incidente.

Es razonable esperar que más organizaciones que utilizan Metabase —ya sea en su versión Cloud o autogestionada— emitan notificaciones similares en las próximas semanas, dado el patrón de exposición documentado.

El Patrón: Cuatro Vulnerabilidades Críticas de Metabase en 2026

Este incidente no ocurre de forma aislada. Es la cuarta vulnerabilidad crítica en Metabase durante 2026 relacionada, directa o indirectamente, con el acceso a credenciales de bases de datos conectadas o con la manipulación de la capa de conexión SQL de la aplicación:

Fecha	Identificador	Mecanismo	Privilegio requerido	Impacto
Febrero 2026	CVE-2026-27464	Inyección de plantillas Handlebars en el sistema de notificaciones por correo	Usuario autenticado de bajo privilegio	Exfiltración de credenciales de bases de datos conectadas vía cuerpo del correo
Abril 2026	CVE-2026-33725	Inyección de propiedad `INIT` en JDBC H2 vía importación de serialización (Enterprise Edition)	Administrador autenticado	Ejecución remota de código y lectura arbitraria de archivos
2026 (pre-agosto)	CVE-2026-59826	Validación insuficiente de propiedades de conexión H2 no seguras	Administrador autenticado	Ejecución de código Java arbitrario en el servidor
Agosto 2026	Sin CVE (GHSA-vwf4-m7j8-wcjf)	Inyección SQL sin autenticación en `/api/session/reset_password`	Ninguno (no autenticado)	Escalada a administrador; robo de credenciales de todas las bases conectadas

El primer caso, documentado en el aviso técnico GHSA-vcj8-rcm8-gfj9 y en el propio post-mortem publicado por Metabase, permitía a un usuario autenticado de bajo privilegio construir una plantilla Handlebars maliciosa en el sistema de notificaciones que filtraba, a través del cuerpo de un correo saliente, objetos de metadatos internos que contenían referencias a credenciales de conexión de base de datos. El segundo, explotado mediante el endpoint POST /api/ee/serialization/import, permitía a un administrador autenticado de Metabase Enterprise inyectar una propiedad INIT maliciosa en la especificación JDBC de H2 durante la sincronización de una importación, logrando ejecución arbitraria de comandos SQL y, en última instancia, de código a nivel de sistema. El tercero, más reciente, consistía en la falta de validación de propiedades de conexión H2 inseguras en una ruta de código de creación de bases de datos, permitiendo a un administrador registrar una conexión H2 manipulada para ejecutar código Java arbitrario en el servidor de Metabase.

Lo que distingue al incidente de agosto de los tres anteriores es que no requiere ningún privilegio ni autenticación previa: mientras las tres vulnerabilidades anteriores exigían al menos una cuenta de usuario válida (y en dos de los tres casos, privilegios de administrador), el fallo actual es explotable por cualquier atacante que pueda alcanzar el endpoint de restablecimiento de contraseña por red. Esa progresión —de fallos que requieren cierto nivel de acceso previo a un fallo pre-autenticación con severidad máxima— es la que convierte a este episodio en el más grave de la serie, y sugiere que la superficie de ataque alrededor de la capa de credenciales y de la integración con H2/JDBC en Metabase merece una revisión de seguridad más profunda por parte del fabricante.

Indicadores de Compromiso y Patrón de Ataque

Metabase no compartió detalles técnicos adicionales sobre la actividad maliciosa observada, pero publicó un patrón de ataque específico y accionable para la detección:

Una solicitud POST /api/session/reset_password que retorna un código de estado 400.
Seguida inmediatamente de una solicitud GET /api/user/current que retorna un código de estado 200.

“Si encuentras ese patrón en tus registros de aplicación o en los registros de ingreso de tu servidor Metabase, es probable que tu instancia haya sido comprometida”, declaró Al-Sakran.

Este patrón es coherente con el mecanismo técnico: la solicitud de restablecimiento de contraseña falla desde la perspectiva de la lógica de negocio normal (de ahí el 400), pero la inyección SQL subyacente logra su objetivo de escalar privilegios o crear una sesión válida, lo cual se confirma cuando la siguiente solicitud a /api/user/current —que requiere una sesión autenticada— responde exitosamente con un 200.

Estado del Parche

El rango de versiones afectadas abarca las ramas 58 a 63, tanto en la edición de código abierto (OSS) como en Enterprise Edition (EE). Las versiones anteriores a la 58 no están afectadas por esta vulnerabilidad específica.

Rama	Versión mínima segura (OSS)	Versión mínima segura (EE)
58.x	0.58.24	1.58.24
59.x	0.59.21	1.59.21
60.x	0.60.17	1.60.17
61.x	0.61.11	1.61.11
62.x	0.62.9	1.62.9
63.x	0.63.5	1.63.5

Los clientes de Metabase Cloud ya cuentan con la versión corregida y no requieren acción. Para instalaciones autogestionadas que no puedan actualizar de inmediato, Metabase recomienda bloquear temporalmente el acceso al endpoint /api/session/reset_password a nivel de red o proxy inverso como mitigación transitoria —una medida que, por ejemplo, el proveedor de hosting Clever Cloud ya implementó de forma automática para todos sus addons de Metabase en versiones afectadas.

Acciones de Remediación en Orden de Prioridad

1. Verificar la versión de Metabase en ejecución desde el menú “Acerca de Metabase” (ícono de engranaje o grilla) y actualizar de inmediato a la versión mínima segura correspondiente a la rama en uso.

2. Si no es posible actualizar de inmediato, bloquear el acceso público al endpoint POST /api/session/reset_password a nivel de firewall, WAF o proxy inverso como mitigación temporal —nunca como sustituto definitivo del parche.

3. Revisar los registros de aplicación y de ingreso del servidor Metabase en busca del patrón de ataque documentado: una solicitud POST /api/session/reset_password con código 400 seguida inmediatamente de una solicitud GET /api/user/current con código 200.

4. Si el endpoint /api/session/reset_password estuvo públicamente accesible, tratar la instancia como potencialmente comprometida y ejecutar, tras aplicar el parche, los siguientes pasos:

Revocar todas las sesiones activas accediendo a la base de datos de aplicación de Metabase y vaciando la tabla core_session.
Revisar las API keys existentes y eliminar cualquier clave no reconocida.
Revisar las cuentas de administrador en busca de cambios inesperados o cuentas nuevas no autorizadas.
Rotar las credenciales de todas las bases de datos conectadas a la instancia, sin excepción.
Revisar los registros de los data warehouses conectados en busca de señales de acceso no autorizado.
Revisar el historial de actividad y de consultas de Metabase en busca de actividad inusual o exportaciones no autorizadas.

5. Auditar la exposición pública del endpoint independientemente de si se detectó explotación: cualquier instancia con /api/session/reset_password alcanzable desde internet debe considerarse de alto riesgo hasta confirmar la aplicación del parche.

6. Para organizaciones que reciban notificaciones de terceros (proveedores SaaS que utilizan Metabase internamente, como ocurrió con Framework, Tally y LexisNexis), tratar la notificación como un incidente de terceros: identificar qué datos propios pudieron haber estado expuestos a través de esa integración y aplicar los controles de respuesta correspondientes, incluyendo el monitoreo de intentos de phishing dirigido que exploten los datos filtrados (nombres, correos, direcciones).

Perspectiva Blue Team: Honeypots e IDS para Herramientas de BI Expuestas

Las herramientas de inteligencia de negocios como Metabase presentan un perfil de riesgo particular para la detección: suelen estar expuestas a internet para facilitar el acceso remoto de usuarios legítimos, concentran credenciales de múltiples sistemas backend, y sus endpoints de autenticación —como el de restablecimiento de contraseña— están diseñados intencionalmente para ser accesibles sin sesión previa. Este perfil exige controles de detección específicos más allá del parcheo.

Honeypots y señuelos

Bases de datos señuelo conectadas a instancias de Metabase de prueba: instancias aisladas con conexiones a bases de datos honeypot que nunca deberían recibir tráfico legítimo. Cualquier consulta ejecutada contra ellas es, por definición, indicativa de acceso no autorizado a través de la capa de BI.
Credenciales honeytoken en el almacén de conexiones: registrar una conexión de base de datos ficticia con credenciales canario dentro de instancias de Metabase de producción permite detectar si un atacante que obtuvo acceso de administrador intenta enumerar o utilizar credenciales almacenadas.
Cuentas de administrador señuelo: cuentas administrativas ficticias dentro de Metabase (no vinculadas a ningún flujo de trabajo real) cuyo uso —inicio de sesión, generación de API key, cambio de configuración— debe generar una alerta crítica inmediata.
Endpoints señuelo adicionales: exponer rutas API adicionales que imiten funcionalidad administrativa sensible puede ayudar a detectar reconocimiento automatizado contra la superficie de la aplicación antes de que el atacante alcance el endpoint vulnerable real.

IDS/IPS y detección basada en comportamiento

Regla de correlación para el patrón de ataque documentado: implementar en el SIEM o WAF una regla que correlacione una solicitud POST /api/session/reset_password con código 400 seguida, dentro de una ventana de pocos segundos y desde el mismo origen, de una solicitud GET /api/user/current con código 200. Esta correlación es el indicador más específico disponible públicamente para este incidente.
Monitoreo de creación de cuentas de administrador: alertar sobre cualquier creación o promoción de cuenta a rol de administrador en Metabase que no esté correlacionada con un ticket de gestión de cambios o una acción documentada por el equipo de plataforma.
Monitoreo de generación de API keys: correlacionar la creación de nuevas API keys con la actividad administrativa esperada; una clave generada fuera de horario o desde un origen no reconocido es una señal de alto valor.
Anomalías de exportación de datos: establecer líneas base de volumen y frecuencia de exportaciones desde Metabase por usuario y por conexión de base de datos; picos repentinos —especialmente hacia destinos o formatos inusuales— deben generar alertas.
Restricción de exposición pública: cuando el caso de uso lo permita, colocar la interfaz de administración de Metabase (y, específicamente, endpoints de autenticación como /api/session/reset_password) detrás de una VPN, un proxy con autenticación adicional, o restricciones de IP a nivel de firewall, reduciendo la superficie disponible para explotación no autenticada.
Reglas WAF específicas para inyección SQL en endpoints de sesión: aplicar reglas de detección de patrones de inyección SQL orientadas específicamente a los endpoints de autenticación y gestión de sesión, no solo a los formularios de consulta expuestos a usuarios finales, ya que estos endpoints suelen recibir menos escrutinio en las políticas de WAF por defecto.
Correlación entre capas: dado que el objetivo final de este tipo de compromisos es el acceso a las bases de datos conectadas, correlacionar la actividad anómala en Metabase con los registros de autenticación y consulta de las propias bases de datos backend permite detectar el “segundo salto” del ataque incluso si la actividad inicial en Metabase pasó desapercibida.

La combinación de estos controles con el marco MITRE ATT&CK (particularmente las técnicas T1190 — explotación de aplicación expuesta a internet, T1078 — uso de cuentas válidas, y T1567 — exfiltración a través de servicios web) permite a los equipos Blue Team construir una capa de detección que no depende exclusivamente de la disponibilidad de firmas específicas para este CVE, sino del comportamiento estructural del ataque.

Cronología del Incidente

Fecha	Evento
19-21 de febrero de 2026	Metabase corrige CVE-2026-27464 (inyección de plantillas en notificaciones que expone credenciales de bases de datos)
Abril de 2026	Metabase corrige CVE-2026-33725 (inyección H2 JDBC INIT vía importación de serialización EE); el 27 de abril se publica un exploit PoC público
2026 (antes de agosto)	Metabase corrige CVE-2026-59826 (bypass de validación de conexión H2 insegura, ejecución de código Java arbitrario)
3 de agosto de 2026 (lunes)	Un atacante no identificado explota el zero-day contra Metabase Cloud; las instancias de Framework y Tally son comprometidas el mismo día
6 de agosto de 2026 (jueves)	Metabase publica el aviso oficial y el advisory técnico GHSA-vwf4-m7j8-wcjf; libera parches para las ramas 58-63; notifica a Framework de la brecha
7 de agosto de 2026	BleepingComputer revela el impacto confirmado en Framework, Tally y LexisNexis; ambas compañías notifican a sus clientes
8 de agosto de 2026	The Hacker News y Security Affairs amplían la cobertura técnica; sin CVE asignado a la fecha de publicación
9 de agosto de 2026	Cobertura continúa; instancias autogestionadas sin parchear permanecen en riesgo activo

Recapitulando…

El zero-day de Metabase confirma, una vez más, una lección estructural sobre las herramientas de inteligencia de negocios: al centralizar credenciales de múltiples fuentes de datos para facilitar el análisis, se convierten en un objetivo de alto valor cuya compromisión no se limita a la aplicación misma, sino que se propaga directamente a todo lo que esa aplicación tiene permiso de leer. Un fallo de inyección SQL sin autenticación en un endpoint tan aparentemente inocuo como el de restablecimiento de contraseña bastó para escalar a acceso administrativo total y comprometer, en cuestión de días, a un fabricante de hardware, una plataforma de formularios y un proveedor de datos legales.

La progresión de cuatro vulnerabilidades críticas en Metabase durante 2026 —de fallos que exigían al menos una cuenta autenticada a un fallo pre-autenticación con severidad máxima— apunta a un problema estructural en la superficie de conexión a bases de datos y gestión de credenciales de la plataforma, más allá de cualquier bug individual. Para los equipos de seguridad, la respuesta inmediata es el parcheo, pero la respuesta sostenida exige tratar cualquier herramienta de BI conectada a datos sensibles con el mismo rigor de segmentación, monitoreo y honeypots que se aplicaría a cualquier sistema con acceso privilegiado a múltiples bases de datos de producción.

Fuentes consultadas: