CVE-2026-72898: puntaje 10.0 en el panel que guarda la contraseña de todas tus bases

Un 10.0 es raro. En la escala CVSS 3.1 solo aparece cuando la falla es explotable por red, sin autenticación, sin interacción del usuario, y además se escapa del componente comprometido para golpear otros sistemas. La CVE-2026-72898 marca 10.0 en las dos escalas, 3.1 y 4.0, y el motivo queda claro apenas recordás qué suele guardar un servidor de Metabase: la credencial de conexión de todas las bases de datos que la empresa alguna vez quiso poner en un gráfico.

La falla en una frase

La CVE-2026-72898 es una inyección SQL (CWE-89) en el endpoint de recuperación de contraseña de Metabase. Un atacante remoto y sin autenticar inyecta SQL arbitrario en la consulta que el flujo de reset ejecuta contra la base de aplicación del propio Metabase, y con eso obtiene acceso de administrador de la instancia. La NVD asigna CVSS 3.1 de 10,0 con el vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, y CVSS 4.0 de 10,0 con CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H.

• Endpoint vulnerable: POST /api/session/reset_password, sin autenticación
• Afectadas: instalaciones self-hosted desde la línea 0.58 / 1.58 en adelante; las versiones anteriores a la 58 no están afectadas
• Corregidas en: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 y 0.63.5, además de las versiones Enterprise equivalentes (1.58.24 y siguientes)
• Divulgada por Metabase el 6 de agosto de 2026, con explotación en producción ya confirmada antes de esa fecha
• Publicada en la NVD el 10 de agosto de 2026 y agregada al catálogo CISA KEV el 11 de agosto de 2026, con plazo de corrección el 14 de agosto de 2026 para las agencias federales estadounidenses
• Mitigación temporal para quien no podía actualizar de inmediato: bloquear el endpoint /api/session/reset_password en el borde

Por qué 10.0 y no 9.8

La diferencia entre 9,8 y 10,0 en CVSS 3.1 está en un único campo del vector: el alcance. Casi toda falla crítica de ejecución remota se queda en S:U, alcance sin cambios, porque el daño ocurre dentro del componente vulnerable. Acá el alcance es S:C, modificado, y esa sola decisión del puntaje ya cuenta la historia del bug.

Lo que el atacante compromete no es solo Metabase. Es la base de aplicación de Metabase, y adentro de ella viven las credenciales que la herramienta usa para consultar las bases de negocio. Tomar el panel da acceso al data warehouse, a la base transaccional, a la réplica de lectura, a todo lo que alguien alguna vez conectó para armar un tablero. Los sistemas golpeados son otros, bajo otra administración, y el puntaje refleja eso.

El mecanismo: un campo que no debería existir en el cuerpo de la petición

El flujo de recuperación de contraseña es de los pocos que tiene que ser no autenticado por naturaleza: quien olvidó la contraseña no puede probar quién es antes de cambiarla. El cuerpo esperado de la petición es chico, un token y la contraseña nueva, y el servidor usa ese token para ubicar al usuario en la base de aplicación.

POST /api/session/reset_password HTTP/1.1
Host: metabase.ejemplo.interno
Content-Type: application/json

{"token": "<token-del-correo-de-reset>", "password": "<contrasena-nueva>"}

# Ese es el cuerpo esperado. La falla no esta en ninguno de esos dos campos.
# El endpoint aceptaba campos NO DECLARADOS en el cuerpo y los pasaba a la capa
# de armado de consulta, que interpretaba el valor como estructura de consulta
# en vez de tratarlo como identificador ya validado. Resultado: un campo extra
# se convierte en expresion SQL dentro de la consulta del flujo de reset.
#
# No publicamos el payload de inyeccion. El punto aca es la clase de bug, no la
# receta: entrada aceptada sin lista de campos permitidos llegando viva hasta el
# constructor de SQL.

La corrección de Metabase sigue exactamente esa lectura: el flujo de reset pasó a aceptar estrictamente los campos esperados, de modo que ningún campo no declarado en el cuerpo influya en la consulta a la base de aplicación. Es la diferencia entre validar lo que recibís y listar lo que aceptás. El primer enfoque intenta adivinar qué es peligroso; el segundo descarta todo lo que no estaba previsto, y por eso no depende de que el desarrollador haya imaginado el ataque de antemano.

Vale aclarar que esto no es la inyección SQL de manual, esa concatenación de strings en un formulario de login. Metabase usa una capa de armado de consulta que, en condiciones normales, parametriza los valores correctamente. La brecha apareció en la frontera entre deserializar el JSON de entrada y alimentar esa capa: un mapa que viene del usuario y se trata como fragmento de consulta en vez de valor. Es un patrón que vemos con frecuencia en stacks modernos, y que pasa desapercibido en revisión justamente porque no hay ninguna concatenación en el código.

El radio de alcance: el BI es el mapa de los datos de la empresa

En muchos inventarios de superficie de ataque, la herramienta de BI queda clasificada como interna y de bajo riesgo. Es un error de lectura fácil de cometer, porque el producto parece pasivo: solo muestra gráficos. Solo que para mostrar un gráfico necesita conexión persistente, credencial almacenada y, casi siempre, permiso de lectura amplio sobre las bases de producción. Ninguna otra aplicación de la empresa suele concentrar ese alcance.

• Acceso administrativo a la instancia, lo que incluye crear cuentas, cambiar permisos y apagar controles
• Las credenciales de conexión de todas las bases configuradas, y por lo tanto acceso directo a ellas con los privilegios que tiene la herramienta
• Consulta y exportación de cualquier dato alcanzable por esas conexiones, sin necesidad de tocar la base por la red
• Los secretos disponibles al proceso en ejecución, incluidas las integraciones configuradas en la instancia
• El historial de preguntas y tableros, que funciona como un mapa comentado de dónde están los datos sensibles

Ese último ítem es el que se suele subestimar. El historial de consultas de un Metabase corporativo es documentación lista: dice qué tabla guarda clientes, cuál guarda transacciones, qué columna tiene el documento fiscal y qué join produce la base completa. Un atacante que necesitaría días explorando el esquema recibe eso masticado, escrito por quien conoce el negocio.

Lo que ya pasó

La falla fue explotada antes de existir como CVE. Metabase divulgó el problema el 6 de agosto de 2026 después de detectar un ataque real contra su propia infraestructura de nube a principios de ese mes, bloquear el endpoint y publicar las versiones corregidas. El identificador CVE recién salió el 10 de agosto, y la CISA incluyó la falla en el catálogo KEV el 11 de agosto, con plazo de tres días para las agencias federales estadounidenses bajo la directiva BOD 26-04. Tres días es el plazo reservado a fallas que reúnen los cuatro criterios de mayor riesgo: activo expuesto a internet, presencia en el KEV, explotación automatizable y control total del sistema una vez explotada.

Del lado de las instancias self-hosted, el relevamiento de Dataminr del 8 de agosto identificó cerca de 11 mil instalaciones probables de Metabase alcanzables por internet, de las cuales 4.309 aparentaban correr una versión vulnerable. Más del 97% de los hosts identificados en las líneas afectadas seguían sin corregir en ese barrido, dos días después de la divulgación. La distribución incluye gobierno, salud, energía, finanzas, telecom y aviación.

Al menos tres empresas que usaban la versión en la nube confirmaron públicamente acceso indebido a datos de clientes en la ventana anterior al parche: Framework, Anaconda y n8n. En el caso de Anaconda, Kilo Code confirmó exposición de tokens de acceso a Slack de usuarios de su función de bot. También apareció una mención a Metabase en un blog de extorsión atribuido a ShinyHunters, pero la autoría sigue sin confirmar y no la tratamos como hecho.

Cómo verificar si tu instancia fue usada

Actualizar no responde la pregunta que importa después de una falla con explotación activa y endpoint público: ¿alguien ya pasó por acá? En este caso existe un patrón de log bastante específico, señalado por la propia Metabase, que sirve de punto de partida para la cacería en el historial del proxy inverso o del balanceador.

# Patron a buscar en los logs de acceso, misma sesion/IP y en secuencia:

POST /api/session/reset_password   -> 400
GET  /api/user/current             -> 200

# La lectura: el intento de reset fallo (400), pero justo despues la peticion
# que solo responde 200 con una sesion valida respondio 200. Es decir, se
# obtuvo una sesion sin un flujo de autenticacion valido en el medio.
#
# Recorte rapido sobre un log combinado de proxy inverso:
grep -E 'reset_password|api/user/current' access.log \
  | awk '{print $1, $4, $7, $9}' \
  | sort -k1,1 -k2,2

Si el endpoint estuvo accesible desde internet en algún momento de la ventana, la recomendación oficial va más allá de actualizar. Las sesiones emitidas antes del parche siguen válidas después de él, y una clave de API creada por un administrador falso sigue funcionando incluso con la falla corregida. La persistencia no desaparece con el upgrade.

-- Ejecutar en la base de APLICACION de Metabase, despues de actualizar.
-- Invalida todas las sesiones activas, incluidas las creadas por el atacante.
DELETE FROM core_session;

-- Despues, en el panel y fuera de el:
--   1. revisar y borrar claves de API que no reconozcas
--   2. auditar la lista de administradores y los cambios recientes de permisos
--   3. rotar la credencial de TODAS las bases conectadas a la instancia
--   4. revisar los logs del data warehouse por consultas o exports fuera de patron
--   5. revisar el historial de actividad y de preguntas dentro de Metabase

El ítem 3 es el más caro y el más salteado. Rotar credenciales de base de producción exige ventana, coordinación y alguien dispuesto a asumir el riesgo de tirar abajo un reporte. Es exactamente por eso que queda para después, y exactamente por eso que importa: la credencial robada es lo que sobrevive al incidente.

Qué cambia en el alcance del pentest

En los alcances que nos llegan, la herramienta de BI casi no aparece. Cuando aparece, entra como aplicación de apoyo, al final de la lista, con prioridad baja. La CVE-2026-72898 es el argumento listo para invertir ese orden, y la inversión no depende de que esta falla puntual siga existiendo: el radio de alcance de la herramienta es estructural, no es consecuencia de un bug.

• Actualizá a 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 o 0.63.5, según la línea en la que estés, y confirmá la versión en ejecución en vez de confiar en lo que dice el repositorio de deploy
• Sacá Metabase de internet abierta: acceso por VPN o por proxy autenticado, y el endpoint de reset nunca expuesto públicamente
• Revisá el permiso de cada conexión configurada; un panel de BI rara vez necesita usuario con escritura, y casi nunca necesita superusuario
• Tratá la instancia como sistema que procesa datos personales a efectos de cumplimiento de privacidad, porque es lo que hace, e incluila en la evaluación de impacto
• Hacé la cacería retroactiva en el log de acceso por el patrón 400 seguido de 200 antes de dar el caso por cerrado, aunque la instancia ya esté actualizada
• Incluí BI, orquestador de datos y herramienta de ETL en el alcance del próximo pentest, con peso de sistema crítico, y no como aplicación interna de bajo riesgo

Este post es educativo y orientado a la defensa. No publicamos exploit funcional ni el payload de inyección: los fragmentos de arriba reproducen el formato documentado de la API del producto, el indicador de compromiso divulgado por el propio proveedor y los pasos de remediación del advisory oficial. Lo que queremos dejar registrado es la lectura de riesgo. Si tu herramienta de BI cae, no cae un tablero con ella, cae el contenido de todas las bases que puede ver.