Summary
An unauthenticated SQL injection in self-hosted Metabase is being actively exploited and rated as CVSS 10.0 and listed on CISA’s KEV list. Terra’s agents reproduced the exploit, triaged every customer environment, and built a preventative control customers can deploy in one click while they schedule the upgrade.
What Happened
On August 6, Metabase disclosed that an attacker had used an unknown vulnerability against Metabase Cloud. The flaw is now tracked as CVE-2026-72898 (GHSA-vwf4-m7j8-wcjf) and carries a CVSS v3.1 score of 10.0.
The mechanics are simple. A crafted POST to /api/session/reset_password lets an unauthenticated attacker inject arbitrary SQL against the Metabase application database. Root cause is a failure to reject undeclared fields in the request body, so an attacker-supplied structure reaches a user lookup as structured input instead of a validated string, and the query builder interprets it as SQL. No credentials or user interaction are required, and the network is reachable.
Affected versions are self-hosted Metabase from x.58 through x.63.4, across the 58 through 63 branches. Anything below 0.58 / 1.58 is unaffected. Fixed releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5, plus the matching 1.x Enterprise builds. Metabase Cloud is already patched.
CISA added the CVE to the Known Exploited Vulnerabilities catalog on August 11, with a federal remediation deadline of August 14 and under BOD 26-04. A verified Nuclei template is public. Wiz Research reported self-hosted metabased in roughly 14% of cloud environments, with about a quarter of those fully internet accessible, and an estimated 2,500 instances reachable from the internet.
Worse Than the CVSS Suggests
A 10.0 already means “stop reading and go patch.” But the score describes the injection. It does not describe what a BI platform is for.
Metabase exists to hold connection credentials to the systems that matter most: production databases, warehouses, and replicas. Admin access on the instance means the attacker can change application configuration, pull stored credentials for every connected database, read anything those connections can reach, and export it. The credential store is the objective, and this SQL injection is the front door.
n8n disclosed on August 8 that an attacker queried its Metabase environment and took 136 customer records, five of which contained bcrypt-hashed passwords. This isn’t just an upgrade situation. Compromise here means credential rotation across every connected data store, LDAP bind accounts, SMTP, API keys, and warehouse tokens.
Validating If Your Environment Is Exploitable
Terra’s agents reproduced the exploit against the affected versions and confirmed the full path from unauthenticated request to administrative access. Proving exploitability is the part that changes your next move. It is the difference between “we appear to run an affected version” and “this specific instance is reachable and exploitable right now.”
By running continuous, change-based testing, Terra customers know what is exploitable and reachable. The Prevention feature enables a temporary control, a specific rule that blocks the exploit path at the WAF or firewall, giving teams time to remediate in full.
Each Customer is notified promptly and is given approval control to make the change. This is deliberate. Pushing a rule into a production edge is an authorized action, and authorizing it belongs to the customer, not to an agent. The work of writing, targeting, and validating the rule is ours. The decision is theirs and takes one click.
To confirm the control is live, the Terra Platform retests and makes non-deterministic attempts to exploit the proven vulnerability, and reports back whether the path is actually closed and if others were found. A rule that was deployed is not the same as a rule that works, and the retest is what turns a compensating control into a control that actually compensates.
Everyone Needs Time
Prevention buys time. It does not replace the upgrade, and the need to rotate credentials.
The fix for CVE-2026-72898 is running a patched Metabase build. What Prevention does is close the exploit path during the window between “we know we are exposed” and “the upgrade is tested and deployed.” For most teams that window is days. For teams running Metabase on a change-controlled release train, it is longer. Attackers are working inside that window right now, which is exactly why CISA put a deadline on it.
Not a Terra Customer?
Upgrade to the patched release for your branch. Confirm the build number in the release notes rather than trusting a latest tag.
If you cannot upgrade today, block or restrict access to POST/api/session/reset_password at your edge.
Get Metabase off the internet. It is an internal analytics tools. Put it behind VPN, ZTNA, or at minimum an IP allowlist and an SSO=enforcing reverse proxy.
Assume credential exposure if you were reachable and unpatched. Rotate connected database credentials, LDAP bind accounts, SMTP, API keys, and warehouse tokens.
Hunt backward at least two weeks. One published indicator: a POST to /api/session/rest_password returning HTTP 400 followed by a successful GET /api/user/current returning 200. Also audit admin accounts for unexpected creation, privilege changes, email changes, or password resets, and review quest history alongside warehouse logs.
Pattern Recognition
This CVE followed the shape that is becoming standard. Zero-day used in the wild, vendor disclosure, public advisory, working exploit template within days, KEV listing with a deadline measured in hours.
Point-in-time testing does not help you here. A pentest report from March tells you nothing about an endpoint that became exploitable in August. What helps is knowing your inventory continuously, being able to prove exploitability on the specific instance you own, and having a way to close the path before the change window opens.
That is the cycle Terra is built to address and Terra customers experienced it live this week.
