Metabase CVE-2026-72898 Exploited: Patch and Check Now

Short answer: CVE-2026-72898 is a critical SQL injection flaw in self-hosted Metabase, the open source dashboard and reporting tool. An attacker with no account can become a Metabase administrator, then read data from every database Metabase is connected to. Singapore's Cyber Security Agency warned on November 4, 2026 that it is being actively exploited and that a public proof-of-concept exists. Upgrade to the fixed release for your version, then follow the clean-up steps below.

The key facts

SQL injection means an attacker sneaks database commands into a request that the application then runs. Here, the target is Metabase's own application database. Metabase's advisory says that from admin access an attacker "could change the application configuration, steal stored credentials for the connected databases, read any data accessible through those connections, and export data."

Metabase found the flaw after its own Cloud service was attacked using it as a zero-day (an unknown, unpatched bug). The patch has been out since August, so any self-hosted instance still unpatched in November is a likely target.

Step 1: find your version

In Metabase, click the gear icon, then About Metabase (or Help, About Metabase). Compare it with this table:

Step 2: upgrade

Back up the Metabase application database first. Then upgrade within your major version. For Docker:

docker pull metabase/metabase:v0.63.5
# Enterprise: docker pull metabase/metabase-enterprise:v1.63.5

For the JAR, download the matching file from downloads.metabase.com and restart. If you cannot upgrade today, block /api/session/reset_password at your reverse proxy as a stopgap. In nginx:

location = /api/session/reset_password { return 403; }

Step 3: check your logs for the attack pattern

Metabase says a likely compromise looks like a POST /api/session/reset_password returning 400, followed by a GET /api/user/current returning 200 from the same client. Search your Metabase logs and your proxy or ingress logs:

grep -E "reset_password|/api/user/current" access.log

Step 4: clean up, even if the logs look clean

If the reset password endpoint was reachable from the internet, Metabase recommends doing all of this after upgrading:

1. Revoke every session by deleting all rows in the core_session table of the Metabase application database.
2. Review API keys and delete any you do not recognise.
3. Review administrator accounts for unexpected changes.
4. Rotate the passwords for every connected database.
5. Review your data warehouse logs for unauthorised access.
6. Review Metabase activity and query history.

Logs may not go back far enough to rule out an attack from August onwards, which is why the credential rotation matters.

Common mistakes

• Upgrading but skipping the session revocation, so a stolen admin session keeps working.
• Rotating the Metabase admin password but not the connected database passwords, which are what attackers want.
• Assuming the blocked endpoint workaround is a fix. It only stops new attempts.
• Leaving Metabase reachable from the whole internet. Put it behind a VPN or single sign-on where you can.
• Thinking an older version is safer because it is old. Only versions below 58 are unaffected.