Metabase's CVSS 10 SQL injection was patched in August — and it's still being exploited in November

Singapore's Cyber Security Agency published an alert on 4 November saying that CVE-2026-72898, a CVSS 10.0 flaw in Metabase, is under active exploitation and has a public proof-of-concept. What caught my attention is the calendar: the vendor advisory is dated 6 August. That is three months between "patch available" and "government agency warns that people are still getting hit", and it's exactly the gap self-hosters live in.

What the bug is

According to the GitHub advisory GHSA-vwf4-m7j8-wcjf, an unauthenticated remote attacker can inject arbitrary SQL into the Metabase application database and potentially gain administrator access. The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: network, no privileges, no user interaction, changed scope. The affected endpoint is /api/session/reset_password, which is reachable before login by design, since a locked-out user has to be able to call it.

The advisory is blunt about the impact: from admin, an attacker can change configuration, steal the stored credentials for connected databases, read data through those connections and export it. That last part is why the application-database framing undersells it. Metabase's own database is rarely the interesting target; the warehouse credentials it stores are.

Versions and the fix

The advisory lists patched releases for each supported line: 58.24, 59.21, 60.17, 61.11, 62.9 and 63.5. The Metabase security update says versions below 58 are not vulnerable, and that Metabase Cloud was already patched after the vendor's own Cloud environment was attacked through this zero-day. The CSA alert expresses the same ranges in the 0.x and 1.x numbering (for example 0.63.0 to before 0.63.5, and 1.63.0 to before 1.63.5), so check which scheme your image tag uses before concluding you are fine.

If you can't upgrade right away, the documented workaround is to block /api/session/reset_password at the reverse proxy. A Traefik or nginx rule returning 403 for that path takes a minute to write. Note that this breaks self-service password resets until you remove it.

Were you already hit?

Metabase gives a concrete indicator of compromise: a POST /api/session/reset_password returning 400, followed by a GET /api/user/current returning 200, which likely means the instance was compromised. Grep your proxy logs for that pair. Upgrading alone does not evict an attacker who already has a session, so if the endpoint was ever publicly reachable, the advisory's cleanup list matters:

Delete all rows in the core_session table, review API keys, check admin accounts for unexpected changes, rotate credentials for connected databases, and review warehouse logs and Metabase query history.

I'm paraphrasing the order slightly, but those are the steps, and the credential rotation is the one people skip because it touches other systems.

My takeaway is boring but sharp. A pinned latest-less tag and a quarterly "I'll update the dashboards box" habit is precisely how an August advisory turns into a November incident. If a tool holds the keys to your databases and sits on the internet, it belongs on the same patch clock as your reverse proxy, not the one you use for hobby services. I'm checking my own tags tonight.