Metabase CVE-2026-72898: la inyección SQL que entrega tu base de datos sin pedir credenciales

El 3 de agosto de 2026, Metabase detectó actividad maliciosa contra su servicio Cloud que explotaba una vulnerabilidad desconocida. Tres días después, el 6 de agosto, la empresa publicó un advisory de seguridad confirmando una inyección SQL no autenticada con CVSS 10.0 — el puntaje máximo posible. El 11 de agosto, CISA añadió el identificador CVE-2026-72898 a su catálogo Known Exploited Vulnerabilities con fecha límite de remediación para agencias federales del 14 de agosto. Para cualquier equipo que opere Metabase on-premises, esa misma ventana de 72 horas aplica a su realidad operativa.

Qué es exactamente la vulnerabilidad

CVE-2026-72898 es una falla de inyección SQL (CWE-89) en el endpoint de restablecimiento de contraseña (/reset_password) de Metabase. Un atacante remoto, sin autenticación y sin interacción del usuario, puede inyectar SQL arbitrario contra la base de datos interna de la aplicación Metabase. Esa base de datos no contiene los datos de negocio del cliente — contiene la configuración de Metabase, las credenciales almacenadas para cada conexión a fuentes de datos downstream, y los mappings de permisos por grupo.

Lo que hace devastadora a esta falla no es la inyección SQL en sí, sino lo que desbloquea. Una vez que el atacante ejecuta SQL con éxito dentro del proceso de la aplicación, puede crear o modificar cuentas de administrador. Con acceso administrativo a Metabase, hereda la capacidad de consultar cualquier fuente de datos conectada — almacenes Snowflake, data warehouses BigQuery, clusters Postgres internos, conexiones a servicios S3 — y de ejecutar SQL nativo contra ellas. En despliegues donde las conexiones de Metabase utilizan credenciales con permisos elevados, eso significa lectura directa sobre producción.

La vulnerabilidad también permite exfiltrar las credenciales almacenadas. Metabase guarda las contraseñas de conexión a cada base de datos en su propio esquema interno; un atacante con acceso de lectura puede extraerlas en texto plano y reutilizarlas fuera de Metabase, contra las bases de datos reales, ampliando el blast radius mucho más allá del panel de BI.

Versiones afectadas y vector de explotación

El rango de versiones afectadas es extenso: cualquier Metabase entre x.58.0 y x.63.4 está en riesgo. Esto cubre seis ramas mayores de release, algo atípico para una vulnerabilidad de esta severidad. La razón es que el endpoint vulnerable — la lógica de reset de contraseña que escribe en la tabla de usuarios — ha mantenido la misma estructura defectuosa a lo largo de múltiples releases. Los parches salieron el 6 de agosto para todas las ramas afectadas (x.58, x.59, x.60, x.61, x.62, x.63), y los administradores deben actualizar a la última versión de su rama.

El vector de ataque es HTTP(S). El atacante envía una solicitud crafted al endpoint de reset con un payload que rompe la construcción del query SQL. La complejidad de ataque es baja, no requiere credenciales ni interacción, y la EPSS (Exploit Prediction Scoring System) asigna una probabilidad de explotación del 10.4%. CISA no pone CVE en KEV por sospecha — lo pone por confirmación, y la inclusión del 11 de agosto confirma que existe explotación activa en producción real, no solo prueba de concepto en laboratorio.

Por qué importa a los equipos de datos

Metabase es una de las plataformas de BI open-source más desplegadas del mundo. Su caso de uso típico es servir como capa de autoservicio sobre un data warehouse: analistas de negocio ejecutan queries ad-hoc, equipos de producto construyen dashboards, y la organización expone métricas a stakeholders sin pasar por el equipo de analytics central. Esa misma accesibilidad que la hace útil es la que amplifica el riesgo: una vulnerabilidad en Metabase compromete toda la superficie de datos conectada.

A diferencia de un servidor de aplicación tradicional, donde una inyección SQL podría exponer datos de un único servicio, Metabase es un agregador por diseño. Una sola instancia suele tener entre 5 y 50 conexiones activas a sistemas downstream — una mezcla de Postgres, MySQL, BigQuery, Snowflake, Redshift, MongoDB, y APIs externas vía conectores. Si tu instancia tiene conexiones de producción, un atacante con admin en Metabase tiene visibilidad sobre todas ellas. Si esas conexiones utilizan cuentas de servicio con permisos amplios (un anti-pattern común en Metabase porque el panel de admin no obliga a scoping fino), el atacante tiene también capacidad de escritura.

El equipo de Horizon3 que descubrió la vulnerabilidad documentó el vector en detalle y publicó un análisis técnico con la timeline de remediación. Metabase respondió en 72 horas — un ciclo de respuesta razonable para una vulnerabilidad crítica de día cero — pero la realidad operativa es que muchas organizaciones corren Metabase con weeks-to-months de retraso en parches, especialmente en clusters Kubernetes autogestionados donde la actualización requiere coordinación con Helm charts, persistent volumes, y pipelines de CI.

Línea de tiempo confirmada

3 de agosto de 2026: Metabase descubre ataques contra Metabase Cloud que explotan una vulnerabilidad previamente desconocida y comienza investigación y contención.

6 de agosto de 2026: Metabase publica advisory de seguridad para CVE-2026-72898, confirmando la vulnerabilidad como inyección SQL no autenticada crítica con explotación activa. Versiones parcheadas disponibles para todas las ramas afectadas (x.58 a x.63).

11 de agosto de 2026: CISA confirma explotación activa y añade CVE-2026-72898 a su catálogo KEV con fecha límite de remediación para agencias federales del 14 de agosto.

La ventana entre descubrimiento y parche fue de tres días. La ventana entre parche y entrada en KEV fue de cinco días. Esas dos ventanas juntas definen la zona de máximo riesgo: el exploit funcionaba en producción, ya existía en manos de atacantes antes del advisory, y los equipos que no parchearon dentro de esa primera semana quedaron permanentemente expuestos.

Qué hacer ahora si operas Metabase

Primero, identifica instancias: cualquier Metabase on-premises o auto-hospedado entre x.58.0 y x.63.4 está en riesgo. Busca en tus registries de Docker, repos de Helm, manifests de Kubernetes, y cualquier documento de inventario. Si usas Metabase Cloud, el proveedor ya aplicó el parche — pero revisa los logs de acceso de tu tenant para actividad sospechosa previa al 6 de agosto.

Segundo, parchea de inmediato. Actualiza a la última versión disponible de tu rama (x.58.25+, x.59.22+, x.60.18+, x.61.12+, x.62.10+, x.63.5+ como mínimo, según tu rama). Si corres Metabase en Kubernetes, coordina la actualización con tu pipeline de Helm o Kustomize — los rolling restarts en deployments con StatefulSets y persistent volumes requieren orden específico.

Tercero, asume compromiso si no parchaste antes del 6 de agosto. La evidencia de explotación activa existía desde el 3 de agosto, antes del advisory público. Revisa los logs de aplicación de Metabase buscando:

- Solicitudes anómalas al endpoint /reset_password con payloads extensos o caracteres especiales en parámetros esperados. - Creación o modificación de cuentas de administrador fuera de tu proceso de provisioning habitual. - Conexiones salientes desde el pod de Metabase hacia IPs externas no esperadas (indicador de exfiltración de credenciales). - Cambios en la configuración de conexiones a bases de datos — strings de conexión modificados, credenciales rotadas sin ticket correspondiente.

Cuarto, rota todas las credenciales almacenadas en Metabase. No asumas que solo las cuentas admin podrían haber sido leídas. Cualquier credencial que Metabase guardó — para bases de datos internas, data warehouses, APIs externas — debe considerarse comprometida y rotada en el sistema destino.

Quinto, revisa el scoping de permisos de las conexiones. Este incidente es una oportunidad para dejar de usar cuentas de servicio con permisos amplios y pasar a cuentas con permisos mínimos por dataset, por operación, y por tiempo de vida. Metabase soporta OAuth para muchas conexiones modernas y tokens con expiración corta para APIs; úsalos en lugar de contraseñas estáticas.

Mitigaciones temporales si no puedes parchear hoy

Si hay una razón operacional que retrasa el parche — un cluster en proceso de migración, un entorno regulado con ventanas de cambio estrictas, una dependencia downstream que requiere testing — hay mitigaciones parciales que reducen pero no eliminan el riesgo.

Bloquea acceso al endpoint /reset_password en tu proxy reverso o API gateway. No es una solución completa porque el vector podría tener rutas alternativas, pero reduce la superficie atacable al patrón documentado. Implementa WAF rules que bloqueen payloads sospechosos al endpoint: requests con UNION SELECT, comillas no escapadas en campos de email, o longitudes anómalas en parámetros de URL.

Coloca Metabase detrás de autenticación de red adicional. Si tu Metabase no necesita ser público, restríngelo a una VPN o zero-trust network access. La vulnerabilidad requiere acceso HTTP al endpoint vulnerable; eliminar el acceso de red no público elimina el vector.

Habilita logging detallado del endpoint y monitoriza agresivamente. Cualquier hit al /reset_password desde una IP fuera de tu inventario conocido debe generar alerta.

Ninguna de estas mitigaciones es un sustituto del parche. Son defensivas temporales mientras coordinas la actualización. El parche es la única solución completa.

Lecciones estructurales

CVE-2026-72898 no es solo un bug en Metabase. Es un patrón que se repite en toda herramienta de BI, dashboarding, y agregación de datos: software que por diseño concentra acceso a múltiples sistemas downstream, con credenciales almacenadas, y con endpoints públicos. Tableau, Looker, Superset, Power BI Embedded — todos tienen el mismo perfil de riesgo. La pregunta no es si otra vulnerabilidad de este tipo aparecerá en otra plataforma, sino cuándo.

Para equipos de plataforma de datos, este incidente refuerza tres prácticas que no son opcionales:

Principio de menor privilegio en credenciales almacenadas. Cada conexión de Metabase a una base de datos downstream debe usar una cuenta con los permisos mínimos necesarios para las queries que el panel ejecuta. Si tu dashboard de ventas solo lee de una vista específica, la cuenta de servicio debe poder solo leer esa vista — no toda la base de datos, no escribir, no crear tablas.

Rotación regular de credenciales. Las credenciales en cualquier sistema agregador son tan seguras como su última rotación. Si Metabase guarda una contraseña que no has rotado en 18 meses, esa contraseña es funcionalmente pública. Implementa rotación automática donde sea posible (Vault con dynamic secrets, IAM roles para AWS, service accounts con expiración corta).

Auditoría periódica de exposición. ¿Quién tiene acceso a tu instancia de Metabase? ¿Qué conexiones tiene configuradas? ¿Cuándo fue la última vez que revisaste las cuentas de administrador? Una auditoría trimestral de 30 minutos detecta configuraciones obsoletas y cuentas huérfanas antes de que un atacante las encuentre.

La vulnerabilidad CVE-2026-72898 es remediada, pero la categoría de riesgo que representa — endpoints públicos que exponen acceso a credenciales internas — va a seguir produciendo incidentes. La diferencia entre un incidente contenido y una brecha masiva será si tu equipo ya tenía estos controles implementados cuando llegue el próximo caso.