Metabase CVE-2026-72898: CVSS 10.0 SQLi on /api/session/reset_password Gave Attackers Admin — Including Metabase Cloud

Introduction

Metabase disclosed in early August that Metabase Cloud had been attacked with a then-unknown bug in versions 1.58 and up. They blocked the endpoints, patched, and told self-hosters to move immediately. The issue is CVE-2026-72898 / GHSA-vwf4-m7j8-wcjf: unauthenticated SQL injection against the application database via POST /api/session/reset_password, leading to administrator access. CVSS 10.0. CISA added it to KEV on August 11. If that endpoint was on the internet, patching is step one; truncating sessions and rotating warehouse credentials is the rest.

What Happened

The password-reset API was annotated to require token and password. Extra JSON keys were not rejected. A 2025 auth refactor started passing the whole body into the auth flow. If a user id was present, Toucan2/select-one looked the user up by that value. HoneySQL treated a raw key as literal SQL. Metabase's own post-mortem: the attack they saw inserted a session for user_id 1 (the first user, always created as admin), browsed data, and minted an API key for bulk downloads.

Unauthenticated. No valid reset token required. Open Source 0.x and Enterprise 1.x across six trains:

Affected First fixed
0.58.0–0.58.23 (and 1.58.x) 0.58.24 / 1.58.24
0.59.0–0.59.20 0.59.21 / 1.59.21
0.60.0–0.60.16 0.60.17 / 1.60.17
0.61.0–0.61.10 0.61.11 / 1.61.11
0.62.0–0.62.8 0.62.9 / 1.62.9
0.63.0–0.63.4 0.63.5 / 1.63.5

Temporary workaround if you cannot upgrade: block /api/session/reset_password at the reverse proxy (this also breaks legitimate password reset).

Hunting pattern Metabase published: POST /api/session/reset_password (or password-reset) returning 400, then GET /api/user/current returning 200.

Why It Matters

Metabase is where analysts live, which means it holds service credentials to production warehouses. Admin on Metabase is SELECT (and often more) on every connected database plus the ability to exfiltrate via questions and API keys. A CVSS 10 on the reset-password URL is as close as BI software gets to "leave the data lake unlocked." The vendor being hit first is the proof it was not theoretical.

Who Is Affected

  • Self-hosted Metabase 0.58+ / 1.58+ below the fixed point releases above
  • Docker, JAR, and cloud-adjacent deploys that were not yet on the patched tags
  • Metabase Cloud customers — vendor mitigated; still rotate anything you stored as database connections if Metabase told you to
  • Indirectly: every warehouse, SaaS DB, and replica the instance could query

How to Protect Yourself

1. Upgrade to the fixed point release for your major, then restart.

# Docker example
docker pull metabase/metabase:v0.63.5
# or the 1.x enterprise tag you run: v1.63.5, v0.62.9, etc.

# JAR: replace the jar with the matching GitHub release, then
java -jar metabase.jar

2. If /api/session/reset_password was public, assume admin was minted. On the application database (Postgres/MySQL — not the warehouses):

-- revoke every session
TRUNCATE TABLE core_session;

Then in Admin → Settings: delete API keys you do not recognize; review administrator users.

3. Rotate every connected-database credential Metabase stored. Review warehouse query logs for bulk extracts around the exposure window. Review Metabase query history / audit for questions and downloads you did not run.

4. Hunt the 400-then-200 pattern in reverse-proxy and Metabase logs:

grep -E 'reset_password|/api/user/current' /var/log/nginx/access.log* /var/log/caddy/* 2>/dev/null

A 400 on reset_password from the internet followed immediately by a 200 on /api/user/current from the same client is Metabase's own compromise signature.

5. Keep the reset endpoint off the public internet even after patching. SSO-only admin, IP allow lists, and no anonymous app on 0.0.0.0:3000.

Source