Metabase CVE-2026-72898: SQLi CVSS 10 sin auth

Si tenés una instancia de Metabase self-hosted expuesta a internet, dejá de leer un segundo y andá a actualizarla: el CVE-2026-72898 es un SQL injection sin autenticación con puntaje CVSS 10.0 —el máximo posible— que ya fue explotado in-the-wild a principios de agosto de 2026. No hace falta usuario, contraseña ni interacción de nadie: un solo POST al endpoint público de reseteo de contraseña alcanza para escalar a administrador y, desde ahí, robar las credenciales de todas las bases de datos conectadas.

CVE-2026-72898 es una vulnerabilidad de inyección SQL sin autenticación en Metabase, la plataforma open-source de business intelligence y dashboards. Reside en el endpoint POST /api/session/reset_password y afecta a las versiones 1.58 en adelante. Un atacante remoto inyecta SQL arbitrario en la base de datos de aplicación de Metabase, se otorga acceso de administrador y puede leer o exportar cualquier dato accesible por las conexiones configuradas. Fue divulgada y parcheada el 6 de agosto de 2026.

¿Cómo un endpoint de reseteo de contraseña termina en acceso de administrador?

Metabase CVE-2026-72898: SQLi CVSS 10 sin auth, ya explotada

Porque el endpoint /api/session/reset_password acepta —sin validarlo— un parámetro no documentado, user-id, que viaja directo hasta el motor de queries. El endpoint espera token y password, pero no descarta las claves extra que le mandes. Según el análisis técnico de Wiz, la falla nace de la combinación de tres comportamientos del stack de Metabase (escrito en Clojure):

El merge de Clojure no filtra claves. Al combinar los datos del request con el resultado de autenticación, las claves extra que mandó el atacante pasan sin ser descartadas.
La keywordización del JSON convierte el payload en un mapa de Clojure. Un cuerpo como {"user-id": {"raw": "SQL"}} se transforma en una estructura de datos nativa en vez de tratarse como texto.
El keyword :raw de HoneySQL embebe SQL sin parametrizar. HoneySQL interpreta {:raw "SQL"} como una orden explícita de insertar ese string crudo en la query, saltándose toda la protección contra inyección.

El resultado es un blind SQL injection controlado por el atacante contra la base de aplicación de Metabase —sea H2, PostgreSQL, MySQL o MariaDB, según cómo esté configurada—. Como el endpoint es público y no requiere sesión, el vector es AV:N/AC:L/PR:N/UI:N: red, complejidad baja, cero privilegios, cero interacción. De ahí el 10.0 redondo.

¿Qué versiones de Metabase están afectadas y a cuál actualizar?

El bug existe desde la 1.58 (cuando se refactorizó el módulo de identidad de autenticación) y hay un release parcheado para cada línea soportada. Estas son las versiones vulnerables y su fix correspondiente, según el advisory oficial GHSA-vwf4-m7j8-wcjf:

Línea	Versiones afectadas	Actualizá a
1.58	≥ 58.0, < 58.24	58.24
1.59	≥ 59.0, < 59.21	59.21
1.60	≥ 60.0, < 60.17	60.17
1.61	≥ 61.0, < 61.11	61.11
1.62	≥ 62.0, < 62.9	62.9
1.63	≥ 63.0, < 63.5	63.5

Verificá la versión exacta que corrés antes de actualizar. Wiz recomienda consultar el endpoint /api/session/properties, que devuelve la versión en el campo correspondiente sin necesidad de loguearte:

curl -s https://TU-INSTANCIA/api/session/properties | grep -i version

¿Ya lo explotaron? Qué pasó en la ventana de principios de agosto

Sí: hubo explotación activa antes de que existiera el parche, lo que lo convierte en un zero-day. La ventana de ataque inicial contra Metabase Cloud fue el 2 de agosto de 2026 y duró alrededor de cuatro horas, según el reporte de The Hacker News. Metabase divulgó el incidente y publicó los fixes el 6 de agosto; para el 10 de agosto ya circulaban PoCs públicos, así que hoy cualquier script kiddie tiene el exploit a mano.

En el comunicado de la propia empresa: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability in versions 1.58 and above" —Metabase, en su aviso de seguridad del 6 de agosto de 2026.

El blast radius no es teórico. Varias empresas que usaban Metabase confirmaron robo de datos a través de esta falla:

n8n confirmó el robo de 136 registros de clientes con nombres y emails; 5 de ellos incluían contraseñas hasheadas con bcrypt de cuentas de n8n Cloud.
Framework reportó acceso a datos de clientes —nombres, IPs de login, direcciones, teléfonos y emails—, aunque sin información de órdenes ni pagos.
Kilo Code vio expuestos tokens de acceso a Slack de su bot; la brecha duró unas cuatro horas y se enteraron cuatro días después.

La superficie de exposición explica la urgencia. De acuerdo con los datos de Wiz, cerca del 13% de los entornos cloud tienen una instancia self-hosted de Metabase desplegada, y aproximadamente el 25% de esas instancias es accesible desde internet. Shodan inventaría unas 2.500 instancias accesibles, según la misma investigación. Cada una de esas es un objetivo con el máximo puntaje de severidad.

¿Qué tenés que hacer hoy si corrés Metabase self-hosted?

Actualizar es necesario pero no suficiente: si tu instancia estuvo expuesta, tenés que asumir compromiso y rotar secretos. El advisory oficial marca este orden:

Actualizá al fix de tu línea (ver la tabla). Si no podés parchear en el momento, la mitigación temporal es bloquear el endpoint /api/session/reset_password en tu reverse proxy.
Revocá todas las sesiones activas. Un atacante pudo haberse dejado una sesión de admin abierta antes del parche.
Revisá y rotá las API keys. Auditá cuáles existen y regenerá las que no reconozcas.
Auditá las cuentas de administrador. El exploit crea o promueve admins; borrá cualquier cuenta que no hayas creado vos.
Rotá las credenciales de todas las bases conectadas. Este es el punto crítico: Metabase guarda las credenciales de tus datasources, y el atacante pudo leerlas. Cambiá esas passwords en cada base, no solo en Metabase.
Revisá los logs en busca de POSTs a /api/session/reset_password con cuerpos que incluyan un campo user-id, especialmente con estructuras anidadas tipo {"raw": ...}.

¿Cómo sé si mi instancia ya fue comprometida?

Buscá en los access logs cualquier POST a /api/session/reset_password con un parámetro user-id en el body. Como es un parámetro no documentado, su sola presencia es sospechosa. Complementá con la revisión de admins nuevos, API keys desconocidas y sesiones activas que no correspondan a tu equipo. Ante la duda, tratá la instancia como comprometida y rotá todo.

Preguntas frecuentes

¿Metabase Cloud está afectado?

Metabase Cloud fue el blanco del ataque inicial del 2 de agosto, pero el proveedor gestiona el parcheo de esas instancias. La acción manual recae sobre quienes corren Metabase self-hosted: son ellos los que tienen que actualizar y rotar credenciales por su cuenta.

¿Alcanza con actualizar la versión?

No. Actualizar cierra la puerta, pero si tu instancia estuvo expuesta antes del parche, el atacante pudo haber leído las credenciales de tus bases conectadas. Rotar esas credenciales es obligatorio, no opcional.

¿Qué motor de base de datos hace más grave el problema?

El injection ocurre contra la base de aplicación de Metabase, sea H2, PostgreSQL, MySQL o MariaDB. Lo que agrava el impacto no es el motor sino qué datasources tengas conectados: cuantas más bases de producción cuelguen de Metabase, mayor es el botín.

¿Por qué el puntaje es 10.0 y no menos?

Porque combina lo peor de cada eje CVSS: explotable por red, sin privilegios previos, sin interacción del usuario, complejidad baja y con impacto total en confidencialidad, integridad y disponibilidad, además de cambio de alcance (scope changed) al saltar de Metabase a las bases conectadas.

Si venís siguiendo la seguridad de infraestructura self-hosted, este caso rima con otros que ya cubrimos: el RCE en CVE-2026-44477 de CloudNativePG y los dos CVEs de Gitea que convertían un header o unas imágenes privadas en acceso total. El patrón se repite: un endpoint que confía de más en la entrada del usuario, y una base de datos entera del otro lado. La lección práctica sigue siendo la misma —no expongas paneles administrativos a internet sin necesidad, y tené un plan de rotación de credenciales listo antes de que aparezca el próximo CVSS 10.