Metabase Exploitation Pulls Connected Databases Into Incident Scope

Metabase disclosed on August 6 that its Cloud service had been attacked through a previously unknown flaw in versions 1.58 and later. The company says it blocked the affected endpoint, patched the vulnerability, and upgraded Cloud customers. Self-hosted branches 58 through 63 can remain vulnerable below the vendor's listed point releases. CVE-2026-72898 allows an unauthenticated remote attacker to inject SQL into the Metabase application database and potentially become an application administrator.

The incident boundary is larger than the Metabase server. Metabase says an attacker with that access could change configuration, steal stored credentials for connected databases, read data available through those connections, and export it. CISA added the CVE to its Known Exploited Vulnerabilities catalog on August 11. Operators should upgrade first, then use the vendor's request pattern to investigate sessions, API keys, administrators, data warehouse credentials, query history, and downstream database activity.

Metabase published its security update on August 6 after detecting an attack against Metabase Cloud. The company describes the issue as an unknown zero-day at the time of the attack and says it immediately blocked the endpoints used, identified the flaw, patched it, and upgraded Cloud instances. The associated GitHub advisory assigns CVE-2026-72898 a critical 10.0 score and states that active exploitation is confirmed.

CISA added the vulnerability to KEV on August 11 with an August 14 due date for covered federal systems under its risk-based update directive. The catalog describes unauthenticated SQL injection into the Metabase application database, followed by possible administrator access, configuration changes, theft of connected-database credentials, queries against reachable data, and export. Known ransomware use is listed as unknown.

Those statements establish urgency without establishing a universal breach. Metabase confirmed an attack on its Cloud service and active exploitation of the vulnerability, but the public material does not identify an actor, victim count, exploit request body, first exploitation date, or every affected Cloud tenant. A self-hosted instance is not proven compromised merely because it ran a vulnerable version. Its exposure, requests, sessions, accounts, and downstream activity still need evidence-led review.

The injection target is the Metabase application database, which stores the service's own operational state. According to the vendor, successful exploitation can produce administrator access to the instance. That is different from SQL injection directly against one analytics warehouse, but it can open a path to every data source the application is authorized to use. Application-level permissions no longer provide a meaningful boundary if an attacker controls the administrator plane.

Metabase explicitly includes stored connection credentials and data accessible through those connections in the potential impact. Scope should therefore start with a graph: the Metabase deployment, its application database, each configured warehouse or operational database, the identity used for each connection, the schemas and tables that identity can read or change, and any export destination or integration reachable from the service. Treat each edge as a separate evidence and credential decision.

Database-side permissions determine the practical blast radius. Metabase recommends a dedicated database user with minimum read privileges for ordinary analytics and separate writable connections for features that need modification rights. An overprivileged shared account can turn control of one BI instance into broad data exposure or write access. A narrowly scoped read-only role cannot prevent the Metabase compromise, but it can reduce what that compromised application is able to do downstream.

Metabase says Cloud customers have already been upgraded. Self-hosted operators need to identify every production, staging, disaster-recovery, development, and embedded deployment. The advisory lists affected branches as 58 through 63 below their fixed point releases. Versions below branch 58 are outside the vendor's affected range, but that fact should not be used as a reason to keep an otherwise unsupported or outdated system in service.

The minimum safe releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 for their respective open-source branches. Commercial builds use the corresponding 1.x numbering. Record the exact running version from the application rather than relying only on an image tag, deployment manifest, or package repository. A container can remain on an old layer after a manifest change, and a rollback can restore the vulnerable build.

Next determine whether /api/session/reset_password was reachable from an untrusted network during the vulnerable period. Check internet-facing load balancers, reverse proxies, ingress controllers, API gateways, alternate hostnames, direct service addresses, and development endpoints. Private placement lowers opportunistic exposure but does not erase risk from a compromised internal host, partner network, or published route. Preserve the exposure timeline because it determines which request and data logs are relevant.

The vendor's primary remediation is to install the safe point release for the branch in use. Follow the normal backup and upgrade process, then verify the version reported by the running instance and all replicas. Confirm that old containers, standby nodes, job runners, and autoscaling definitions cannot return a vulnerable version to service. Health checks should cover authentication, scheduled jobs, database connections, embedding, and any write-enabled analytics feature that depends on the upgraded instance.

If an immediate upgrade is impossible, Metabase says to block /api/session/reset_password temporarily. The wording matters: this is a bridge to the patch, not an alternate permanent design. Apply the block at every reachable ingress and verify it externally. Document the business effect on password recovery, name an owner and expiry, and remove the temporary rule only after all serving instances have crossed the fixed boundary.

Do not wait for investigation to finish before closing the vulnerability. At the same time, do not let the upgrade destroy useful evidence. Preserve application and ingress logs, a defensible snapshot or backup of the application database, deployment metadata, and the pre-upgrade version timeline according to the organization's response process. An emergency image replacement without retained logs can close the exploit path while making the earlier exposure much harder to reconstruct.

Metabase published a specific attack pattern: a POST to /api/session/reset_password that returns HTTP 400, followed by a GET to /api/user/current that returns HTTP 200. The company says finding that sequence in application or ingress logs likely means the instance was compromised. Search for the ordered pair by source, timing, session or cookie context, host, and user agent, while preserving the raw events that support the match.

A single 400 response on the reset endpoint is not the complete pattern, and a normal 200 response from /api/user/current is not suspicious by itself. Conversely, absence of the pair is meaningful only if both paths, status codes, timestamps, and relevant request context were logged for the whole exposure window. Proxies may rewrite source addresses, sampling may omit requests, retention may have expired, and an attacker may vary behavior after the public disclosure.

Correlate any match with new or changed administrator accounts, API key creation and use, configuration changes, unusual sessions, query history, downloads, scheduled work, and traffic from the Metabase host to connected data stores. Review warehouse authentication and query logs using the exact Metabase identities. The public sources do not provide a campaign IP list or file hash, so investigation should follow the confirmed request and resulting authority rather than an invented indicator set.

After upgrading an exposed instance, Metabase tells operators to revoke active user sessions by deleting rows from the core_session table, review API keys and remove unrecognized keys, and inspect administrator accounts for unexpected changes. Perform those operations through a controlled process with a backup and vendor guidance. Session invalidation can disrupt users, but leaving attacker-created or captured authority active defeats the purpose of patching the entry point.

The vendor also recommends rotating credentials for connected databases, reviewing warehouse logs, and examining Metabase activity and query history. Prioritize credentials by demonstrated access and privilege. Coordinate rotation with database owners, replicas, scheduled jobs, secrets managers, and recovery systems so old values are actually revoked rather than merely supplemented. If a connection had write authority, investigate modifications as well as reads and exports.

Longer term, use dedicated least-privilege database identities, separate write-capable functions from ordinary analytics connections, limit administrative and endpoint exposure, centralize ingress and query telemetry, and test session and key revocation. Metabase can encrypt stored connection details at rest with MB_ENCRYPTION_SECRET_KEY, which protects a different failure mode. It does not remove the need for rotation when a live compromised instance may have obtained or used those credentials.