Metabase — the open-source BI tool that sits in front of production databases at a very large number of companies — disclosed a zero-day rated CVSS 10.0, exploited in the wild before anyone knew it existed.
The company found it the direct way. Its own cloud infrastructure was compromised on 3 August. The patch shipped within hours and Metabase Cloud customers were secured automatically.
Everyone self-hosting had to find out and act themselves.
The flaw
Unauthenticated SQL injection into Metabase's application database, via:
POST /api/session/reset_password
No credentials required. Send crafted input to the password-reset endpoint and you are writing SQL into the database that holds Metabase's own configuration — which includes the stored credentials for every database Metabase connects to.
From there: administrator access, configuration changes, credential theft for connected databases, and read or export of anything those connections reach.
The tool's entire value proposition is that it has privileged access to your data. That is also the impact statement.
The identifier problem
| Advisory | GHSA-vwf4-m7j8-wcjf |
| CVSS | 10.0 |
| CVE | None assigned |
This is the detail worth carrying out of the story. A vulnerability with no CVE does not enter the NVD feed, and a scanner built on NVD data has nothing to match against. An organisation running vulnerability management entirely off CVE identifiers had a CVSS 10 with active exploitation in its estate and a clean dashboard.
We made a version of this point about the Kemp LoadMaster flaw that reached CISA's KEV catalogue: the identifier is a routing mechanism, not the vulnerability. When the routing fails, the vulnerability does not care.
Affected and fixed versions
Every release from 1.58 onward, across branches 0.58 through 0.63.
| Affected range | Fixed in |
|---|---|
| ≥1.58.0, <1.58.23 | 1.58.24 |
| ≥1.59.0, <1.59.20 | 1.59.21 |
| ≥1.60.0, <1.60.16 | 1.60.17 |
| ≥1.61.0, <1.61.10 | 1.61.11 |
| ≥1.62.0, <1.62.8 | 1.62.9 |
| ≥1.63.0, <1.63.3 | 1.63.5 |
How to check whether you were hit
Metabase published a concrete indicator pair, which is more useful than most advisories manage:
- A call to
POST /api/session/reset_passwordreturning 400 - Followed by
GET /api/user/currentreturning 200
The 400 is the injection landing. The 200 immediately after is a session that should not exist. If both appear in sequence in your access logs, treat the instance as compromised rather than patched.
The victims are already named
This is not a theoretical severity rating. Three organisations had disclosed by publication:
- Framework — customer names, IP addresses, physical addresses, phone numbers and emails accessed
- n8n — 136 customer records, of which 5 contained bcrypt-hashed passwords
- Kilo Code — Slack access tokens exposed through a Slackbot integration
The Kilo Code case is the instructive one. The exposure was not Metabase data. It was a token for a different system that happened to be reachable from the Metabase environment. That is the blast radius of a BI tool: everything it was ever pointed at.
What to do
- Patch to the fixed release for your branch. Not the latest version — the fixed release on your branch, from the table above.
- Grep for the indicator pair. A 400 on reset_password followed by a 200 on user/current is the signature.
- Rotate every database credential Metabase held, not just the ones you think were touched. The application database stores them; the injection reached the application database.
- Rotate connected-service tokens too. The Kilo Code case shows those go with it.
- Fix your scanner's assumptions. If your vulnerability management only ingests CVE identifiers, this one was invisible. GHSA advisories, vendor bulletins and KEV are separate feeds and need separate ingestion.
The single most repeatable lesson: the tool with read access to everything is not a reporting tool from a risk perspective. It is a credential store with a chart library attached.
