Metabase flaw reaches connected data

What has happened

Metabase says its cloud service was attacked through a previously unknown vulnerability affecting version 1.58 and later. The company blocked the route used in the attack and patched its hosted service. Self-hosted installations are not updated automatically and may remain exposed.

The flaw, CVE-2026-72898, is an unauthenticated SQL injection in a Metabase endpoint. Metabase says successful exploitation can provide administrator access to the application. That position may allow an attacker to alter configuration, obtain stored credentials for connected databases, read information available through those connections and export data. The vendor rates the issue critical and confirms active exploitation. CISA added it to its Known Exploited Vulnerabilities catalogue on 11 August. CISA records ransomware use as unknown; that should not be reported as evidence either way.

Who needs to act

The vendor's advisory covers Metabase branches 58 through 63. Fixed community releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5; corresponding enterprise releases use the 1.x numbering. Metabase says versions below 58 are not affected. Administrators should confirm the actual running build rather than relying on an old inventory or deployment file.

Metabase Cloud customers are already patched, according to the company. Organisations running Metabase themselves, through a hosting partner or inside a managed analytics service should establish who owns the upgrade and whether the affected password-reset endpoint was reachable from the internet. An internal-looking dashboard can still be public through a proxy, forgotten hostname or supplier-managed route.

What defenders should do

Upgrade to the fixed point release for the branch in use. Metabase offers blocking the affected password-reset endpoint as a temporary workaround when an immediate upgrade is impossible, but describes upgrading as the remediation. Do not leave the workaround undocumented or assume it deals with activity that may already have happened.

Where the endpoint was publicly accessible, follow the vendor's post-upgrade response steps. These include revoking active sessions, checking API keys and administrator accounts, rotating credentials for connected databases, and reviewing warehouse, application and query history for unexpected access. Preserve relevant logs before routine retention or maintenance removes them, and involve the incident-response owner if the evidence suggests misuse. Credential rotation should cover what the Metabase instance could actually reach, with care taken not to break dependent services.

• Locate every self-hosted or supplier-operated Metabase instance and record its running version.
• Upgrade each affected branch to the vendor's fixed point release.
• Confirm whether the affected endpoint was publicly reachable before the upgrade.
• Review sessions, keys, administrator accounts and relevant access history.
• Rotate connected-database credentials when exposure warrants it and verify dependent services afterwards.

The Beekeeper view

The difficult part is not recognising that a critical, exploited flaw should be patched. It is finding every instance and understanding the trust placed behind it. Analytics tools often sit close to valuable databases, and a modest-looking web console may hold credentials that reach far beyond its own application data.

Treat the upgrade and the exposure review as one job. A clean version number answers whether the known route remains open; it does not answer whether somebody used it yesterday.