Un resumen rápido sobre una vulnerabilidad confirmada como explotada en la naturaleza (incluida en el catálogo KEV de CISA). Qué hace, quién está afectado y cómo responder, desde una perspectiva defensiva y sin pasos de explotación.
- CVE
- CVE-2026-72898
- Gravedad
- Crítica — CVSS 10.0 (tanto v3.1 como v4.0)
- Clase
- Inyección SQL sin autenticación (CWE-89)
- Impacto
- Acceso de administrador a la instancia de Metabase, con acceso a las credenciales y datos de las bases de datos conectadas
- Afectados
- Metabase autoalojado de la línea x.58 en adelante, por debajo de las versiones corregidas
- Explotación
- En KEV de CISA (añadida el 11 ago 2026, fecha límite el 14 ago); el proveedor indica que fue explotada como vulnerabilidad de día cero
- Solución principal
- Actualizar, más la revocación de sesiones y la rotación de las credenciales de cada base de datos conectada
Por qué no es opción dejarlo pendiente
No se requiere autenticación y el resultado es acceso de administrador, lo que lo convierte en un objetivo prioritario para escaneos indiscriminados; de ahí que se incluyera en KEV el día después de su publicación. El proveedor indica que fue explotada activamente contra su propio entorno en la nube antes de aplicar el parche, así que "todavía nadie ha venido por nosotros" no es una suposición que pueda hacer.
Qué es el fallo
Metabase es una plataforma de BI y analítica que se conecta a sus bases de datos y sirve paneles y consultas sobre ellas. El defecto es que el endpoint que gestiona el restablecimiento de contraseñas construye SQL a partir de un valor proporcionado por quien hace la llamada. Ese procesamiento ocurre antes de la autenticación, por lo que un atacante nunca necesita una cuenta (inyección SQL, CWE-89).
La inyección llega a la base de datos de la aplicación propia de Metabase, la que contiene usuarios, sesiones, claves de API y la configuración de conexiones, es decir, el control de la instancia. La entrada de KEV de CISA indica que, tras obtener acceso de administrador, un atacante puede cambiar la configuración de la aplicación, robar las credenciales almacenadas de las bases de datos conectadas, leer cualquier dato accesible a través de esas conexiones y exportarlo.
Atacante sin autenticación
↓ SQL inyectado mediante el endpoint de restablecimiento de contraseña
Base de datos de la aplicación de Metabase → administrador
↓ configuración de conexiones y credenciales almacenadas
Cada base de datos conectada
ingresos, clientes, registros: todo lo que BI puede leer
Quién está afectado
| Elemento | Detalle |
|---|---|
| Afectados | Metabase autoalojado; el proveedor indica que Metabase Cloud ya está parcheado |
| Versiones vulnerables | La línea x.58 en adelante, por debajo de las versiones corregidas |
| Versiones corregidas | 0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5 (Enterprise: 1.58.24 / 1.59.21 / 1.60.17 / 1.61.11 / 1.62.9 / 1.63.5) |
| Requisito previo | Ninguno: no requiere autenticación |
| Impacto | Acceso de administrador → credenciales y datos de las bases de datos conectadas |
| Solución temporal | Bloquear el endpoint /api/session/reset_password (temporal hasta que actualice) |
Qué hacer
Actualice a la versión parcheada (máxima prioridad, la única solución real)
Si todavía no puede actualizar, bloquee el endpoint
/api/session/reset_password en su proxy inverso o WAF. Considérela estrictamente una medida temporal.Revoque todas las sesiones y, después, audite las claves de API y los administradores
core_session de la base de datos de la aplicación para cerrar todas las sesiones, elimine las claves de API que no reconozca y revise las cuentas de administrador en busca de cambios que no pueda justificar. Si alguien tuvo acceso de administrador, la actualización por sí sola deja en su sitio las cuentas y claves que esa persona creó.Rote las credenciales de cada base de datos conectada (no omita este paso)
Reduzca la accesibilidad en sí
Una pista de detección publicada por el proveedor
El proveedor describe el patrón de explotación como una llamada a /api/session/reset_password que devuelve 400, seguida inmediatamente de una llamada a /api/user/current que devuelve 200. Si todavía dispone de registros de acceso, merece la pena buscar esa secuencia. Si no tiene registros, la respuesta es "desconocido", no "limpio". En ese caso, suponga que hubo compromiso y ejecute el paso 4.
Opinión de este sitio: una herramienta de BI guarda todas las credenciales conectadas, así que protéjala como a su base de datos más sensible
Las organizaciones tienden a clasificar las herramientas de BI y analítica como "cosas que muestran datos" y las gestionan con un nivel de cuidado inferior al de las propias bases de datos. La realidad es la contraria: la herramienta es un único punto que contiene las credenciales de todo lo que conecta. Nuestra posición es que debe protegerse al nivel de la base de datos más sensible a la que da acceso. Eso implica: dar a BI un usuario de conexión con el mínimo privilegio necesario (solo lectura, solo los esquemas que necesita), no exponerla nunca directamente a internet y tener preparado un procedimiento de rotación de credenciales antes de necesitarlo. Si lo hace, incluso en el peor caso, como un fallo en código previo a la autenticación, perderá una conexión en lugar de todas las bases de datos.
Fuentes
- NVD: CVE-2026-72898 (CWE-89; CVSS 10.0 en v3.1 y v4.0)
- Catálogo KEV de CISA: Known Exploited Vulnerabilities Catalog (añadida el 11 de agosto de 2026, fecha límite el 14 de agosto de 2026)
- Proveedor: GHSA-vwf4-m7j8-wcjf y Metabase security update