Metabase Cloud bajo ataque: el zero-day de inyección SQL sin CVE que pone en riesgo a toda tu organización

Una vulnerabilidad zero-day de inyección SQL en Metabase Cloud, la plataforma de analítica empresarial basada en inteligencia artificial, está siendo explotada activamente en producción desde hace días. Lo más grave no es únicamente el compromiso de los clientes directos de Metabase: el verdadero radio de explosión se extiende aguas abajo, a cualquier organización cuyas credenciales, datos y configuraciones internas hayan pasado alguna vez por una instancia conectada. A la hora de escribir este artículo, la vulnerabilidad todavía no tiene identificador CVE asignado, pero Metabase le otorgó una puntuación CVSS máxima de 10.0, la máxima posible, y confirmó que la explotación permite a un atacante remoto inyectar sentencias SQL en la base de datos interna de la aplicación, lo que en la práctica equivale a obtener acceso administrativo total sobre la instancia.

Lo que ya sabemos del ataque

El CEO de Metabase, Sameer Al-Sakran, publicó un post confirmando que su plataforma en la nube fue comprometida por un atacante que utilizó esta falla. La cronología oficial, según el aviso de la compañía en GitHub, muestra que el equipo de seguridad bloqueó inmediatamente los endpoints utilizados durante el ataque, identificó la vulnerabilidad en cuestión de horas y desplegó un parche antes de que la mayoría de los clientes percibieran cualquier anomalía. La mitigación, hasta donde se sabe, se aplicó primero en Metabase Cloud y los binarios self-hosted aún están en proceso de liberación de versiones corregidas para clientes que ejecutan la plataforma en sus propios data centers.

La versión vulnerable es Metabase 1.58 y superiores. Esto significa que cualquier despliegue self-hosted que se haya mantenido al día con las actualizaciones durante el último año está potencialmente expuesto, salvo que el operador haya restringido el acceso a la API en el puerto 3000, que es donde Metabase expone sus servicios por defecto tanto en el contenedor Docker oficial como en la distribución standalone basada en Java.

Johannes Ullrich, investigador principal del SANS Internet Storm Center, ha explicado en declaraciones a Dark Reading que el endpoint vulnerable debe estar alcanzable desde la red del atacante para que la explotación funcione. Ullrich señala que Metabase puede desplegarse como contenedor Docker o como aplicación Java independiente, y que en ambos casos expone la API en el puerto 3000. La pregunta crítica que cada equipo de seguridad debe hacerse hoy mismo es: ¿quién puede acceder al puerto 3000 de nuestras instancias de Metabase? Si la respuesta es algo distinto de un conjunto muy limitado de IPs internas y un balanceador con autenticación adicional, el riesgo es elevado.

El radio de explosión: por qué esto va más allá de Metabase

Lo que convierte a este incidente en algo más serio que una vulnerabilidad habitual en una plataforma SaaS es el rol que Metabase juega en la cadena de datos empresarial. Metabase no es solo una herramienta de visualización: es, en la mayoría de despliegues, el puente entre los data warehouses productivos (Snowflake, BigQuery, Redshift, Postgres, MySQL) y los equipos que necesitan consultar esos datos sin escribir SQL complejo. En consecuencia, una instancia de Metabase comprometida suele tener permisos elevados sobre múltiples bases de datos que contienen información sensible: registros de clientes, datos financieros, telemetría de producción, métricas de negocio, historiales de auditoría.

El aviso de Metabase describe la cadena de explotación con precisión preocupante. Una vez que el atacante consigue inyectar SQL en la base de datos interna de la aplicación, los siguientes pasos son prácticamente automatizables. En primer lugar, el atacante obtiene acceso administrativo a la instancia, lo que le permite cambiar la configuración de la aplicación. En segundo lugar, puede robar las credenciales almacenadas para las bases de datos conectadas, que Metabase guarda internamente para poder ejecutar consultas en nombre de los usuarios. En tercer lugar, puede leer cualquier dato accesible a través de esas conexiones, es decir, todo lo que Metabase podía consultar legítimamente. Y en cuarto lugar, puede exportar esos datos de forma masiva antes de que cualquier monitorización detecte la anomalía.

El resultado práctico es que una organización que nunca tuvo relación comercial directa con Metabase puede terminar viendo sus datos exfiltrados si alguno de sus proveedores, clientes o partners utiliza Metabase para analizar información compartida. Esto convierte al incidente en un problema de cadena de suministro de software en toda regla.

Por qué la mayoría de las instancias están sobreexpuestas

Ullrich añadió una observación que debería preocupar a cualquier equipo que haya desplegado Metabase en producción: la mayoría de los usuarios, según su experiencia, han expuesto sus instancias directamente a la red sin restringir endpoints individuales de la API. La razón, explica, es práctica. Metabase expone varios endpoints que legítimamente necesitan ser alcanzables desde la red corporativa, como el endpoint de restablecimiento de contraseña. Configurar un proxy granular que permita solo los endpoints necesarios y bloquee el resto añade complejidad operativa que muchos equipos prefieren evitar.

Esa decisión, perfectamente comprensible en el momento del despliegue, se convierte hoy en una deuda de seguridad crítica. Si tu instancia de Metabase ha estado escuchando en una interfaz de red accesible desde Internet, desde una VPC compartida con terceros o incluso desde una red de oficina sin segmentación adecuada, debes asumir que ha sido objetivo de intentos de explotación en las últimas dos semanas.

El aviso de Metabase no detalla qué endpoint exacto fue explotado, lo cual es razonable desde el punto de vista de defensa pero dificulta la construcción de reglas de detección específicas. Lo que sí está claro es que la mitigación temporal más eficaz, en espera del parche oficial para self-hosted, es restringir el acceso al puerto 3000 únicamente desde redes conocidas y monitorizar cualquier intento de conexión desde IPs externas.

Medidas de contención que debes aplicar hoy

Si operas Metabase self-hosted en versión 1.58 o superior, la prioridad inmediata es triple. Primero, audita quién tiene acceso al puerto 3000 de cada instancia. Si está expuesto más allá de tu VPC privada o de una lista cerrada de IPs, restringe el acceso de inmediato mediante reglas de firewall o un reverse proxy con autenticación. Segundo, revisa los logs de la instancia buscando patrones de actividad sospechosa desde al menos dos semanas antes de la fecha de divulgación pública del incidente. Busca picos inusuales de errores SQL, conexiones desde IPs desconocidas, cambios de configuración no programados y exportaciones de datos masivos. Tercero, rota todas las credenciales que Metabase tenía almacenadas para bases de datos conectadas, asumiendo que cualquier credencial en la instancia puede estar comprometida.

Si operas Metabase Cloud, el equipo de Metabase ya desplegó la mitigación por ti, pero debes rotar igualmente las credenciales que tu instancia tenía configuradas y revisar quién tuvo acceso a qué datos durante la ventana de exposición. La rotación de credenciales downstream es particularmente importante: cualquier clave de API, token de servicio o contraseña de base de datos que Metabase tuviera almacenada debe considerarse comprometida y debe ser revocada y reemplazada.

Más allá de la respuesta inmediata, este incidente es una oportunidad para revisar tu modelo de confianza en herramientas de analítica empresarial. La pregunta de fondo no es solo si Metabase es seguro, sino si tu arquitectura permite que el compromiso de una sola plataforma SaaS se traduzca en acceso administrativo a múltiples bases de datos productivas. Si la respuesta es sí, tienes un problema de diseño de seguridad que ningún parche va a resolver por ti.

Detección y monitorización continua

Para los equipos de seguridad que necesitan construir detecciones específicas, las señales más útiles tras este tipo de incidente son las siguientes. Volumen anormalmente alto de errores SQL en los logs de la aplicación, especialmente errores que sugieran inyección (presencia de UNION, comillas no escapadas, comentarios SQL en campos que no deberían contenerlos). Conexiones a la API desde rangos de IP que no corresponden a usuarios legítimos, en particular desde proveedores de hosting o VPN residenciales. Cambios en la configuración de la instancia que no se corresponden con despliegues planificados, especialmente cambios en las conexiones a bases de datos, en los permisos de usuarios o en los ajustes de exportación. Y por último, exportaciones de datos masivas o inusuales, sobre todo si se producen fuera del horario laboral habitual o desde cuentas que normalmente no mueven grandes volúmenes de información.

Herramientas SIEM estándar como Splunk, Elastic o Datadog pueden configurarse para alertar sobre estas señales en minutos, siempre que los logs de Metabase estén siendo ingestados de forma centralizada. Si todavía no centralizas los logs de tus instancias de Metabase, este es un buen momento para empezar.

Lo que viene

Metabase confirmó que publicará parches para las versiones self-hosted en los próximos días. Hasta que esos parches estén disponibles y desplegados en producción, la restricción de acceso al puerto 3000 es la única mitigación eficaz. Una vez que el parche esté disponible, la actualización debe tratarse como prioritaria, con la misma urgencia que cualquier otra vulnerabilidad de severidad 10.0, independientemente de que Metabase no haya solicitado todavía un identificador CVE.

Este incidente también pone de manifiesto una limitación estructural del ecosistema de software empresarial: la ausencia de un CVE no significa ausencia de riesgo. La asignación de CVE es un proceso voluntario y lento, y durante la ventana entre divulgación y asignación, las organizaciones que dependen exclusivamente de feeds de vulnerabilidades basados en CVE están ciegas ante la amenaza. Los equipos de seguridad maduros mantienen monitorización de avisos de seguridad de proveedores críticos además del flujo CVE, y este incidente es un recordatorio oportuno de por qué esa práctica es indispensable.