Metabase Zero-Day CVSS 10.0 Grants Full Admin Access Without Authentication
On August 8, 2026, Metabase disclosed a maximum-severity SQL injection flaw (CVSS 10.0) that was already being exploited in the wild. The vulnerability lets unauthenticated attackers gain administrator privileges and drain every connected database. Self-hosted Metabase admins must patch, revoke sessions, and rotate all secrets immediately.
August 8, 2026, 12:24 UTC. The Metabase team publishes advisory GHSA-vwf4-m7j8-wcjf on GitHub. The vulnerability — no CVE assigned as of August 8 — scores a perfect CVSS 10.0. The vector is disarmingly simple: an unauthenticated SQL injection against the /api/setup/validate endpoint that lets a remote attacker escalate to full administrator privileges on the Metabase instance, then reach every connected database.
This is not a lab exercise. Metabase confirms the flaw was exploited in the wild as a zero-day before the patch shipped. Metabase Cloud instances have already been updated server-side. If you self-host Metabase version 1.58 or later, your instance is vulnerable — and possibly already compromised. Patching alone is not enough: you must also revoke all sessions, rotate every secret, and audit your logs.
A trivial SQL injection against an unprotected setup endpoint
Metabase is an open-source business intelligence tool used by data teams to visualise and query databases. It connects to PostgreSQL, MySQL, BigQuery, Snowflake, and roughly thirty other backends. A typical Metabase instance is the single access point for data that is sometimes business-critical: revenue figures, customer records, production pipelines.
The problem sits in the /api/setup/validate endpoint. Normally used during the initial setup phase to validate the connection to the Metabase application database, this endpoint requires no authentication and passes user-supplied parameters directly into a SQL query without adequate sanitisation.
An attacker sends a POST request with a malicious SQL payload in the token parameter. This is a classic SQL injection — no sophisticated bypass, no complex exploit chain. The payload executes with the privileges of the Metabase application database, which contains the core_user, core_session tables and all connection details for external data sources.
# Indicator of compromise: any request to /api/setup/validate
# returning HTTP 200 in Metabase's HTTP access logs
grep '/api/setup/validate' /var/log/metabase/access.log | grep ' 200 'Once holding admin rights, the attacker can:
- Alter the instance configuration and disable logging
- Export all users and their permissions
- Create arbitrary SQL queries and run them against connected databases
- Extract full content from every reachable database through existing connections
- Export data as CSV or JSON through the admin UI
Metabase CEO Sameer Al-Sakran confirmed on the GitHub thread that the company “recently identified that Metabase Cloud was attacked by someone utilising an unknown security vulnerability in versions 1.58 and above.”
Impact: every database connection becomes an exfiltration vector
The severity of this zero-day is not just about privilege escalation — it is the multiplier effect of the connections configured inside Metabase.
A Metabase instance connected to three data sources means the attacker can potentially drain three separate databases after obtaining admin access. In enterprise deployments, Metabase is often wired to data warehouses (Snowflake, Redshift, BigQuery) holding years of transactional history.
Metabase has also published a specific indicator of compromise: any request to /api/setup/validate returning an HTTP 200 status code in the application server logs. If you find this pattern in your nginx logs or Metabase ingress logs, your instance is very likely compromised.
One affected company, whose name was not disclosed, publicly confirmed being targeted by this exploit. It stated that no order or payment data was accessed — a finding that suggests the attacker was specifically going after analytical databases rather than transactional systems.
The 2023 precedent: history repeating
This is not Metabase’s first critical vulnerability. In July 2023, CVE-2023-38646 (CVSS 9.8) enabled pre-authenticated remote code execution through the /api/setup/validate endpoint — the same endpoint implicated today.
The 2023 fix introduced additional validation, but it was evidently insufficient to cover all execution paths. Three years later, the same endpoint betrays its users again. The pattern is documented and predictable: a setup endpoint that outlives the setup phase, left exposed without authentication, forwarding user input straight to a database.
The lesson for application security teams is clear: a setup endpoint must never survive the setup phase. If it must remain reachable, it should be protected by the same authentication level as the rest of the application.
How to respond: patching alone is not enough
Metabase published the fix on August 8, 2026 through a security update. Applying the patch is immediate and non-optional — but it is only the first step in a longer checklist.
Here is the full procedure recommended by Metabase:
1. Apply the patch. Upgrade to the latest Metabase version. Metabase Cloud instances have already been updated; self-hosted users must apply the fix manually.
2. Revoke all active sessions. Connect to the Metabase application database (the one you configured during installation) and run:
DELETE FROM core_session;This invalidates every existing session token and forces all users — including the attacker — to re-authenticate.
3. Review API keys and tokens. Examine the core_user table and the API key list in the admin interface. Revoke any key you do not recognise.
4. Rotate database connection secrets. The credentials for data sources connected to Metabase are stored in the application database and may have been read by the attacker. Change the passwords of all connected databases.
5. Audit data warehouse query logs. Check the query logs of your source databases (PostgreSQL, Snowflake, BigQuery, etc.) for suspicious activity matching the compromise timeframe.
6. Review Metabase activity. Use the built-in audit view (Admin > Audit) to identify unusual SQL queries or unauthorised data exports.
Verdict
If you self-host Metabase version 1.58 or later and have not yet applied the August 8 fix, shut down the instance now and follow the procedure above in order. Patching alone does not protect against an already-realised compromise — session revocation and secret rotation are just as critical as the upgrade.
For new instances, two hardening rules are mandatory: place Metabase behind a reverse proxy with authentication (even basic auth), and remove the /api/setup/validate endpoint after initial setup. This endpoint has no reason to exist after the first launch.