Vulnerabilidad zero-day en Metabase es explotada activamente
El 8 de agosto de 2026, la plataforma de inteligencia de negocio open-source Metabase publicó un aviso de seguridad por una vulnerabilidad de severidad máxima que, durante al menos una semana antes de la divulgación, había sido utilizada para comprometer instalaciones en producción de su propia nube y, por extensión, los datos de los clientes que habían confiado a esas instancias telemetría operativa sensible. El fallo, registrado como GHSA-vwf4-m7j8-wcjf y CVE-2026-72898, obtuvo una CVSS v3.1 de 10.0 y permite a un atacante remoto no autenticado inyectar SQL arbitrario en la base de datos de aplicación de Metabase y obtener privilegios totales de administrador. Un CVSS de 10.0 es el techo de la escala; se reserva a problemas sin autenticación, sin interacción del usuario y de baja complejidad de ataque.
La vulnerabilidad reside en el endpoint POST `/api/session/reset_password`, una ruta pública y sin autenticación a la que responde cualquier instancia de Metabase alcanzable en internet. La causa raíz es un fallo a la hora de restringir campos no declarados en el cuerpo de la petición de reseteo de contraseña. El endpoint espera un `token` y un `password`; si quien llama envía además un parámetro no documentado llamado `user-id`, la aplicación lo acepta, lo enhebra a través de un `merge` de Clojure que no elimina claves desconocidas, y pasa ese valor a la consulta que resuelve la cuenta que se va a resetear. En lugar de ser tratado como un identificador entero, el valor es interpretado por HoneySQL, la capa de construcción de consultas de Metabase, como una entrada estructural. Cuando el atacante envía `{"user-id": {"raw": "SQL"}}`, la palabra clave `:raw` en HoneySQL se compila como SQL literal sin comillas y sin parámetro ligado, y la petición se convierte en una inyección SQL ciega en la base de datos de la aplicación.
El CEO de Metabase, Sameer Al-Sakran, confirmó la cronología: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability." Los primeros indicios de compromiso se detectaron el 2 de agosto de 2026, y la empresa pasó a bloquear los endpoints utilizados por los atacantes, para luego parchear el fallo. El aviso no se publicó hasta el 8 de agosto, lo que dejó a los defensores seis días de ventana en los que el exploit se estaba utilizando en la naturaleza. Al mediodía UTC del 10 de agosto, código de prueba de concepto público circulaba abiertamente, amplificando el grupo de atacantes que podían reproducir el mismo ataque.
El indicador de compromiso que debería estar en cada pipeline
La regla de detección más sencilla que Metabase publicó es también la que la mayoría de los defensores terminará usando. Un atacante que consiga éxito contra una instancia sin parchear dejará un patrón muy específico en los logs: una petición `POST /api/session/reset_password` que devuelve HTTP 400 (se espera un token de reseteo malformado, la inyección viaja en un campo inesperado), seguida en cuestión de segundos por una petición `GET /api/user/current` que devuelve HTTP 200. La primera petición es el intento; la segunda es el atacante verificando que acaba de ser ascendido a una sesión de Metabase. Al-Sakran fue explícito: "If you find that pattern in your application logs or in your server ingress logs, it is likely that your instance has been compromised."
Ese patrón de dos peticiones es lo bastante fiable como para promoverlo a una alerta dura en cualquier entorno que ejecute Metabase y que todavía no haya rotado la base de datos de aplicación. El endpoint en sí también debería bloquearse en el balanceador o en el WAF para cualquier organización que no pueda parchear en 24 horas. Bloquearlo romperá el reseteo de contraseña para usuarios legítimos, pero en un período de explotación zero-day activa ése es un coste mucho menor que dejar pasar la siguiente petición.
Del endpoint al control administrativo total
La razón por la que una inyección SQL en un único endpoint basta para tomar el control de una instancia de Metabase es que la base de datos de aplicación almacena mucho más que registros de usuario. Contiene la configuración de la propia instancia, las claves de API para integraciones salientes, las cuentas de administrador y, lo más dañino desde la perspectiva de pérdida de datos, las credenciales de las bases de datos que Metabase ha sido configurado para consultar. Una vez que el atacante puede leer y escribir la base de datos de aplicación, puede autopromocerse a administrador, cambiar la configuración de alarmas para que nadie más sea notificado y usar las propias conexiones de Metabase para consultar el data warehouse subyacente como lo ve Metabase. También puede exportar datos a través de los endpoints de exportación integrados, lo que significa que todo lo que los usuarios legítimos pueden ver, el atacante puede descargarlo.
La firma de seguridad Wiz, que ha rastreado la exposición a Metabase en su base de clientes, ha puesto la superficie de ataque en un contexto sombrío. Aproximadamente el 13 por ciento de los entornos cloud ejecutan una instancia self-hosted de Metabase, y de ésas, cerca del 25 por ciento son alcanzables desde internet. La misma investigación identificó unas 2.500 instancias de Metabase visibles en Shodan en los días previos a la divulgación, y el número de instancias vulnerables era lo bastante grande como para que CISA añadiera el fallo a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV) con fecha límite de remediación del 14 de agosto de 2026 para las agencias federales.
Las víctimas que han hablado
Tres de las compañías más destacadas en divulgar brechas vinculadas a esta vulnerabilidad lo hicieron en las 48 horas siguientes al aviso de Metabase, y el panorama es coherente con el peor escenario para una inyección SQL contra una BI.
**Framework**, el fabricante de portátiles modulares, reveló que un atacante accedió a su instancia de Metabase el 3 de agosto de 2026, el día después de que Metabase notara por primera vez la explotación. El conjunto expuesto incluía nombres completos, correos, direcciones IP de inicio de sesión, direcciones de facturación y envío, números de teléfono y nombres de empresa. Los clientes de Framework Business tenían campos adicionales, incluidos números de IVA y EIN. La información de pedidos y pagos no fue accedida (el procesamiento de pagos vive fuera de Metabase), pero el conjunto es más que suficiente para habilitar phishing dirigido y los intentos de toma de cuentas que se basan en nombre, dirección y correo.
**Tally**, la plataforma de formularios, reportó que su entorno de analítica fue comprometido el mismo día, 3 de agosto, y que los atacantes obtuvieron correos y hashes de contraseñas para los usuarios afectados. Las respuestas y envíos de formularios en sí no estaban en el alcance de la instancia de Metabase, lo que limitó el peor escenario, pero la combinación de correo y hash obligará a un reseteo forzado de contraseñas y a una ronda de detección de credential-stuffing.
**Kilo Code**, la plataforma de coding con IA, reveló que la brecha expuso tokens de autenticación de su Slackbot para los usuarios afectados. La ventana del incidente fue de cuatro horas el 2 de agosto, y la compañía notificó a los usuarios días después. Los tokens de Slack robados son una categoría particularmente desagradable de secreto porque otorgan el mismo alcance de acceso que el usuario legítimo y seguirán funcionando hasta que se revoquen explícitamente; rotarlos es la única respuesta correcta.
**n8n**, la plataforma de automatización de workflows, también fue confirmada como afectada. La divulgación registró 136 registros de cliente con nombres y correos, y cinco registros expusieron hashes bcrypt de contraseñas para cuentas de n8n Cloud. La investigación de n8n también sacó a la luz un bug histórico de abril de 2023 que había dejado 25 cuentas con almacenamiento en texto plano de sus contraseñas originales de registro.
La matriz de parches y por qué importa
Metabase se distribuye en seis líneas de release soportadas activamente, y el parche se entrega como un release coordinado en todas ellas a la vez. Las versiones corregidas son 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9 y 1.63.5. La versión afectada más antigua es 1.58.0, y toda instalación en 1.58 o superior es vulnerable hasta que se haya actualizado a una de las releases corregidas en su rama. Los clientes cloud fueron parchados automáticamente; los self-hosters, la población que Wiz ha rastreado en el 13 por ciento de los entornos cloud, tienen que hacer la actualización por su cuenta.
El arreglo se describe en el aviso como una restricción explícita del flujo de reseteo de contraseña a las entradas esperadas. El endpoint ahora deja de aceptar campos no declarados, lo que aborda la causa raíz en vez de enmascararla. Para las organizaciones que ya han sido comprometidas, el parche por sí solo no basta. La lista de remediación de Metabase es más larga que el paso de actualizar: revocar sesiones activas eliminando filas de `core_session`, revisar y eliminar claves de API no reconocidas, auditar las cuentas de administrador en busca de adiciones inesperadas, rotar las credenciales de cada base de datos conectada y revisar tanto los logs de acceso del data warehouse como el historial de actividad y consultas de Metabase. Ninguno de esos pasos es opcional en una situación de "¿fuimos nosotros?", porque la base de datos de aplicación es la fuente de verdad sobre quién tiene acceso de administrador a la instancia, y cualquier fila comprometida que se deje en su sitio es un pie que el atacante puede volver a establecer.
El patrón más amplio: por qué las BI son un objetivo blando
El incidente de Metabase no es la primera vez que una plataforma de BI es el punto de pivote de una brecha de gran alcance, y no será la última. El problema estructural es que estas herramientas se asientan en la costura entre los datos operativos y la gente que quiere verlos, y suelen ser operadas por equipos cuya experiencia principal son los datos, no la seguridad de la aplicación que los muestra. La base de datos de aplicación de una BI contiene las llaves del data warehouse y las credenciales de sólo lectura que el resto de la compañía utiliza, lo que significa que una inyección SQL contra ella es funcionalmente equivalente a una inyección SQL contra el data warehouse.
El fallo específico en el caso de Metabase, un endpoint público y sin autenticación que tolera campos no declarados y los reenvía a un constructor de consultas que los interpreta como SQL, es una clase de bug que se repite porque los frameworks que lo hospedan suelen ser anteriores a los modelos de amenaza que lo habrían cazado. El `merge` de Clojure hace lo que `merge` siempre ha hecho. El `:raw` de HoneySQL hace lo que `:raw` se diseñó para hacer. La aplicación de esos primitivos a un endpoint de autenticación alcanzable públicamente es el verdadero error, y el único arreglo durable está en el endpoint.
Para los defensores, la lección operativa es la misma que la industria lleva una década re-aprendiendo: la inyección SQL más peligrosa es la que un atacante sin autenticación puede alcanzar por la internet pública, la que le da acceso administrativo a la aplicación que frontaliza los datos que le importan, y la que aún no han parchado. El zero-day de Metabase cumplió los tres a la vez, y las organizaciones afectadas están pagando ahora el coste de una ventana de seis días previa a la divulgación en forma de confianza de usuarios, esfuerzo de respuesta a incidentes y rotaciones de credenciales.
Aplicar el parche es el primer paso. Los siguientes, revocación de sesiones, rotación de claves, rotación de credenciales y revisión de logs, cierran el ciclo.
Qué deberían hacer los defensores en las primeras 24 horas
La forma de la respuesta para cualquier organización que ejecute una instancia self-hosted de Metabase entre 1.58.0 y 1.63.4 depende de si la respuesta a "¿vemos el patrón de IoC en los logs?" es sí, no o desconocida. La rama no es la sencilla: aplicar el parche en la próxima ventana de mantenimiento, revisar el changelog del upgrade y escribir una nota breve en el runbook que registre el patrón de IoC. La rama desconocida es el lugar de arranque correcto en la mayoría de organizaciones, porque el estado por defecto de cualquier despliegue de analítica es "tenemos logs, pero no hemos buscado este patrón en los últimos diez días".
Para el caso desconocido, la primera acción es consultar los logs de aplicación y los de ingress en busca del patrón de dos peticiones que Metabase publicó. Una comprobación de `POST /api/session/reset_password` devolviendo 400 seguida por `GET /api/user/current` devolviendo 200 es una forma inicial razonable. Si hay cualquier hit, la organización está en la rama sí y la lista de remediación anterior aplica en su totalidad. Si el resultado es limpio, la prioridad pasa a la higiene de upgrades.
La rama sí es más compleja. La primera acción es sacar la instancia afectada de la internet pública mientras la limpieza está en curso, porque mientras siga alcanzable, el atacante puede volver por el mismo camino. La segunda acción es actualizar a la versión parcheada. La tercera acción es el trabajo de respuesta a incidentes: revocar sesiones, auditar cuentas de administrador, rotar credenciales de bases de datos, buscar exportaciones que nadie del equipo hizo y notificar a las partes interesadas legales y de cumplimiento.
La cuarta acción, a menudo olvidada, es tomar una imagen forense de la base de datos de aplicación antes de que la limpieza empiece. La limpieza sobrescribirá las filas que cuentan la historia de la respuesta, y el writeup post-incidente necesitará saber qué cuentas de administrador se añadieron, qué sesiones se acuñaron y qué consultas se ejecutaron entre el primer POST y el descubrimiento. La forma más barata de preservar esa evidencia es un `pg_dump` cuando se confirma el incidente.
La lección para los vendors de productos adyacentes
La divulgación de Metabase es un espejo útil para los equipos que operan otras herramientas de BI, plataformas de observabilidad y dashboards internos. La clase de vulnerabilidad, un endpoint público y sin autenticación cuyo input es interpretado como SQL por un constructor de consultas que ya no aplica la frontera de identificador, no es exclusiva de Metabase. El mismo patrón se puede encontrar en cualquier producto que creció alrededor de un constructor de consultas lo bastante expresivo y exponía sus endpoints a internet.
La respuesta defensiva de ingeniería es la misma en todos los casos: el contrato del endpoint debería ser el conjunto más pequeño posible de campos nombrados, y cualquier campo que no esté en ese contrato debería rechazarse en el borde antes de que pueda fusionarse en las estructuras de datos que alimentan la consulta. El arreglo es local, el patrón es universal, y la divulgación de CVE-2026-72898 es un buen momento para auditar cada herramienta adyacente que el equipo de ingeniería opera y confirmar que la misma validación de inputs está presente allí también.