Metabase: el panel de datos que también era el llavero

El 3 de agosto alguien entró en instancias de Metabase alojadas por el propio fabricante y se llevó datos de sus clientes. No hubo phishing, ni contraseña filtrada, ni administrador descuidado. Hubo una petición POST a /api/session/reset_password —el endpoint del «he olvidado mi contraseña», el único que por definición tiene que responder sin sesión— que aceptaba SQL. El aviso salió el 6 de agosto con un CVSS de 10.0, el máximo de la escala. Framework y Tally ya han avisado a sus usuarios. Y el detalle que convierte esto en algo más grande que un parche urgente: lo que un atacante se lleva de un Metabase comprometido no son los gráficos.

Lo que hay dentro de un panel de BI

Metabase es un visor. No es donde viven tus datos: es lo que los consulta. Para poder consultarlos guarda, en su propia base de datos de aplicación, los datos de conexión de cada base de datos que le hayas enchufado: host, puerto, usuario y contraseña. Y la inyección de este aviso va exactamente contra esa base de datos de aplicación. No contra el almacén de datos: contra la libreta donde están apuntadas las llaves del almacén.

El aviso del fabricante lo enumera sin adornos: un atacante en una instancia comprometida puede cambiar la configuración de la aplicación, robar las credenciales guardadas de las bases de datos conectadas, leer cualquier dato accesible a través de esas conexiones y exportarlo. Léelo otra vez con tu instalación en la cabeza y haz la cuenta de cuántas bases de datos tiene conectadas tu Metabase. Ese número no es «cuántos orígenes tengo». Es cuántos sistemas se comprometen a la vez.

Hay una capa más, y es la que mucha gente descubre esta semana: esas credenciales no están cifradas por defecto. La documentación de Metabase presenta el cifrado de los detalles de conexión como algo que activas tú, creando una clave y poniéndola en la variable de entorno MB_ENCRYPTION_SECRET_KEY. Si nadie la puso el día del despliegue —y en un despliegue hecho con prisa nadie la pone—, ahí están, tal cual.

Ahora el matiz, que nos importa más que el titular: ponerla no te habría salvado, pero te habría salvado la mitad. La inyección va contra la base de datos de aplicación, no contra el entorno del proceso: si los detalles están cifrados, lo que sale de esa tabla es un bloque AES inútil sin la clave, y eso sí le quita al atacante la contraseña en claro que se lleva puesta para después. Lo que no evita es que, ya dentro como administrador, le pida al propio Metabase que ejecute la consulta: el panel descifra, conecta y le enseña los datos igual. Cifrar no cierra la ventana de este incidente, pero reduce mucho lo que el atacante conserva cuando la ventana se cierra, que es justo la parte cara, como se ve más abajo. Póngala quien no la tenga.

La cuenta de servicio que nadie ha vuelto a mirar

La conexión se crea el primer día, cuando la prioridad es que el gráfico salga. Se usa el usuario que había a mano, o se crea uno nuevo con permisos anchos «para que se vean todas las tablas y no tener que volver a tocarlo». Nadie vuelve a tocarlo, efectivamente. Dos años después ese usuario sigue teniendo lectura sobre todo el esquema, y ahora su contraseña ha estado en un sitio al que se llegaba sin autenticarse.

Y hay un multiplicador poco comentado: un administrador de Metabase puede escribir SQL nativo contra las conexiones. Es decir, el atacante que se promociona a administrador no necesita conocer tu modelo de datos, ni adivinar nombres de tabla, ni traerse herramientas. Se lo pregunta al panel, que para eso está, y el panel se lo enseña ordenado y con un botón de exportar. Si tu conexión usa un usuario de solo lectura acotado a un esquema concreto, el daño se acota con ella. Eso no es hardening avanzado: es cómo se debería haber creado la conexión el primer día.

Un agujero que tu inventario de parches no ve

El fallo se publicó como aviso de seguridad de GitHub, GHSA-vwf4-m7j8-wcjf, y en el momento de escribir esto no tiene CVE asignado. Merece la pena pararse aquí, porque tiene consecuencias operativas concretas: si tu proceso de gestión de vulnerabilidades consiste en recibir un boletín de CVEs y cruzarlo con una lista de productos, este agujero de puntuación 10.0 y explotado en la vida real no aparece. No hay nada que cruzar. Para tu proceso, no existe.

No es una rareza de este caso. Los proyectos alojados en GitHub publican ahí sus avisos, y el CVE es un trámite aparte que a veces llega tarde y a veces no llega: este, con un 10.0 y explotación confirmada, seguía sin él cuando escribimos esto. La diferencia práctica está en qué vigilas: quien vigila versiones —un inventario con lo que hay instalado y una comparación periódica contra las notas de publicación del fabricante— se entera el mismo día. Quien vigila CVEs, se entera cuando alguien se lo cuenta.

Mira bien el número antes de decir que no te afecta

Los rangos afectados del aviso son 58.0 a 58.22, 59.0 a 59.19, 60.0 a 60.15, 61.0 a 61.9, 62.0 a 62.7 y 63.0 a 63.2. Las versiones corregidas son 58.24, 59.21, 60.17, 61.11, 62.9 y 63.5. Y una advertencia sobre esas dos listas: no se tocan. El aviso marca como afectado todo lo anterior a la 63.3, pero corrige en la 63.5; marca lo anterior a la 62.8, y corrige en la 62.9. Si tu número cae en ese hueco —una 62.8, una 63.3, una 63.4— el aviso literalmente no dice nada de ti. Nosotros iríamos a la versión corregida y no al borde del rango: es la única de las dos listas de la que el fabricante afirma que lleva el arreglo dentro.

Aquí hay una trampa de lectura que va a hacer que alguien archive el aviso por error. Buena parte de la cobertura dice «afecta desde la 1.58», y tú miras tu contenedor, lees v0.62.4 y respiras. No respires. Metabase antepone un 0 o un 1 según la edición: el 0 es la versión libre y el 1 la comercial de los planes Pro y Enterprise, con el mismo número de versión detrás. Un v0.62.4 y un v1.62.4 son el mismo número de versión en dos ediciones: la comercial trae funciones de más, pero para mirar el rango de este aviso cuentan igual. Así que «desde la 1.58» y «las ramas 0.58 a 0.63» dan exactamente los mismos números.

Las versiones anteriores a la 58 no están en el rango. Con una salvedad que decimos sin sonrisa: si tu consuelo hoy es que llevas dos años sin actualizar, tu problema no es más pequeño, es otro. Y si no puedes actualizar en las próximas horas, el propio aviso da la medida provisional que sirve: bloquear el endpoint /api/session/reset_password en el proxy o el balanceador que tengas delante. Se rompe el «he olvidado mi contraseña» y no se rompe nada más.

Y hay una comprobación que puedes hacer ahora mismo, sin herramientas: el patrón que se publicó como indicio es un POST a /api/session/reset_password que devuelve 400, seguido, desde la misma IP y en cuestión de segundos, de un GET a /api/user/current que devuelve 200. Es decir: la petición «falla», y acto seguido esa misma IP está autenticada. Sin correlar por origen y por tiempo el patrón no vale nada, porque un 200 en /api/user/current lo genera cualquier navegador con la sesión abierta. Si guardas los logs del proxy, es una búsqueda de dos minutos. Si no los guardas, ya has encontrado la primera tarea de la lista.

Actualizar es la mitad fácil

La lista de después del aviso —que el fabricante condiciona a que tu endpoint fuera accesible desde internet— tiene seis puntos: borrar todas las filas de la tabla core_session en la base de datos de aplicación, revisar las claves de API y eliminar las que no reconozcas, repasar los cambios en cuentas de administrador, rotar las credenciales de las bases de datos conectadas, examinar los registros de acceso del almacén de datos y revisar el histórico de actividad y consultas del propio Metabase. Cinco de esos seis se hacen en una tarde.

El cuarto no, y es el que decide si el incidente se cierra de verdad. Rotar la contraseña de la conexión significa tocar la base de datos de producción, coordinar una ventana, avisar a quien depende de esos informes y arriesgarse a romper el cuadro de mando que dirección mira los lunes. No se parece en nada a actualizar un contenedor: son horas de coordinación en vez de minutos de despliegue, así que se anota «para la semana que viene». Y la semana que viene el Metabase está limpio, parcheado, con los administradores revisados… y el atacante conserva una credencial válida contra tu base de datos de producción, que es lo que se llevó. Es el mismo patrón que contábamos con el servidor de CI/CD que guarda las llaves de producción: parchear el sistema no rota lo que el sistema guardaba.

¿De quién es el panel?

Un Metabase casi nunca lo instala el departamento de IT. Lo levanta el equipo de datos, el de producto o el de marketing, porque necesitaban una gráfica el jueves y era un docker run. Es una buena herramienta y esa facilidad es una virtud, no un reproche. El problema es lo que arrastra: nace fuera del inventario, fuera de la ventana de actualización, fuera de la lista de lo que se parchea, y con un puerto publicado «temporalmente» para que lo vea el comercial que está de viaje.

Hay una medida de esto, y no es de esta semana. En marzo de 2026, un estudio de OX Security contaba más de 17.000 instancias de Metabase publicadas en internet según Shodan, muchas de ellas en versiones vulnerables a un fallo de ejecución remota de 2023. El informe no cuantifica cuántas de esas 17.000 seguían sin parchear, y no vamos a inflar el dato: lo que sí dice es que tres años después de publicarse el parche, el fallo se sigue encontrando en internet a miles. Ese es el suelo sobre el que llega un aviso de puntuación 10.0.

La pregunta operativa es la de siempre, la que ya nos hicimos con quién mantiene tu WordPress: si esta mañana sale un aviso crítico de tu herramienta de BI, ¿a quién le llega el correo? Si la respuesta es «a quien la instaló, si sigue en la empresa», el problema no es de Metabase. Y si la respuesta es «no sé si tenemos», ese es el hallazgo de hoy.

El endpoint es público por diseño; internet no tiene por qué serlo

Vale la pena fijarse en dónde estaba el agujero, porque no es casualidad. El endpoint de recuperar contraseña es, por definición, el que tiene que responder a quien no puede autenticarse. Está en la puerta, delante del control de acceso, en todas las aplicaciones del mundo. La pregunta interesante no es si ese endpoint debe existir —debe—, sino quién debe poder llamarlo.

Un panel de BI es una herramienta interna. Detrás de una VPN, o de un acceso publicado por identidad como el que montamos en los proyectos de Zero Trust, este mismo fallo pasa de «cualquiera con conexión a internet es administrador de tu panel» a «alguien que ya está dentro puede serlo». No lo elimina, y no vamos a fingir que sí. Reduce la población de atacantes posibles de varios miles de millones a tu plantilla, y convierte una carrera de horas contra bots en un incidente que se investiga con nombres. Contra el argumento habitual —«es que la gente lo consulta desde casa»—: eso es una necesidad legítima y tiene tres o cuatro soluciones, y ninguna de ellas es publicar el login en internet.

Y luego está la parte que no decides tú

Framework y Tally no aparecen en esta historia por descuidados. Framework ha explicado que Metabase le notificó el 6 de agosto que su instancia había sido accedida el día 3, y lo que salió fueron nombres, correos, direcciones y teléfonos de clientes. Tally habla de correos y hashes de contraseñas. Ninguna de las dos empresas tenía un servidor sin parchear: tenían un proveedor.

Esa es la parte incómoda de esta clase de incidentes, y la que peor cubren los cuestionarios de proveedor. Cuando preguntas a un tercero «¿qué herramientas procesan nuestros datos?», la respuesta casi nunca incluye el panel interno con el que su equipo mira las métricas de tu cuenta. No por mala fe: porque para ellos ese panel no es un sistema que procese datos de cliente, es la pantalla donde miran cómo va el mes. Vale la pena añadir la pregunta al cuestionario, y vale la pena poder contestarla tú si te la hacen.

El orden en que lo haríamos nosotros

• Encuentra los paneles. No los del inventario: los que hay. Un docker ps en los servidores del equipo de datos y una vuelta por los registros del DNS interno suelen dar más de una sorpresa.
• Compara la versión con el rango, ignorando el 0 o el 1 del principio. Actualiza a 58.24, 59.21, 60.17, 61.11, 62.9 o 63.5 según tu rama.
• Busca el patrón 400 y luego 200 desde la misma IP en los logs del proxy, desde principios de agosto hacia atrás. Y revisa la lista de administradores nombre a nombre: la promoción a administrador es el objetivo del ataque, y una cuenta de más es la prueba.
• Rota las credenciales de cada base de datos conectada. Todas. Es la tarea cara, la que se pospone y la única que le quita al atacante lo que se llevó. Aprovecha para cambiarlas por usuarios de solo lectura acotados, que es la conversación que lleva pendiente desde el primer día.
• Mírate desde fuera. ¿Responde tu panel desde una IP de internet? Si sí, ponle una puerta antes de que acabe la semana.
• Y lo permanente: que el panel tenga un dueño con nombre, esté en el inventario y que alguien reciba las notas de publicación del fabricante. Sin eso, del siguiente aviso también te enterarás por la prensa.

Cuándo esto duele menos (y cuándo solo lo parece)

Si usas Metabase Cloud, el parche no es tu trabajo: el fabricante bloqueó los endpoints del ataque y actualizó las instancias alojadas sin que tú hicieras nada. Pero que el parche no sea tuyo no te saca de la lista, más bien al contrario: las dos instancias comprometidas que conocemos con nombre —Framework y Tally— eran instancias alojadas. Revisa la lista de administradores, cierra sesiones y rota las credenciales de las bases conectadas exactamente igual que si el servidor fuera tuyo. El parche cierra la puerta; no deshace lo que pasó antes de cerrarla. Si estás por debajo de la versión 58 no estás en este rango, aunque, como decíamos arriba, eso te pone en otro peor. Y si tu panel nunca ha sido accesible fuera de una red de gestión y la conexión usa un usuario de solo lectura acotado, actualiza con calma y rota cuando toque: tu exposición real es pequeña y decirlo es más útil que asustar.

Lo que no vale como consuelo es «es que ahí solo hay datos de ventas». Los datos de ventas son nombres, correos, teléfonos y direcciones de tus clientes, y salir por la puerta de un panel no los convierte en otra cosa. Es exactamente lo que Framework ha tenido que contarle a los suyos esta semana.

Nosotros no vendemos Metabase ni ninguna herramienta de BI, y esto no es un argumento contra ella: es una buena pieza de software con un fallo grave y una respuesta rápida del fabricante. El trabajo que sí hacemos es el de alrededor —saber qué aplicaciones internas hay, quién las mantiene, qué credenciales guardan y a quién dejamos llegar a ellas— dentro de los proyectos de ciberseguridad y de datos y aplicaciones del día a día. Si no sabes cuántos paneles hay enchufados a tus bases de datos ni con qué usuario se conectan, escríbenos y lo miramos contigo.