Metabase CVSS 10.0: One Unauthenticated API Call Hands Attackers Admin Keys to Your Entire Analytics Stack

Every BI tool your organisation runs is a potential crown-jewel database. Metabase — the open-source analytics platform trusted by thousands of enterprises to query their most sensitive data — has just confirmed that attackers chained a single unauthenticated SQL injection call into full administrator access, no credentials required. Three organisations have already disclosed breaches: laptop maker Framework, form-builder Tally, and legal-data giant LexisNexis. The attack began on 3 August 2026. Metabase pushed patches on 7 August — but with no CVE identifier assigned and no automated scanner alert to trigger, most self-hosted instances are still wide open.

What Is Metabase and Why Should Enterprises Care?

Metabase is one of the most widely deployed self-service BI platforms in the world, used by organisations ranging from startups to Fortune-500 companies to query production databases, data warehouses, and SaaS back-ends. When you connect Metabase to PostgreSQL, MySQL, BigQuery, Snowflake, or any of its forty-plus supported data sources, you store live database credentials inside its configuration. An attacker who owns your Metabase instance does not need to find your cloud secrets manager or pivot through your network — they simply read the credentials Metabase already holds and connect directly to your data.

That is why a CVSS 10.0 rating in a BI tool is categorically more dangerous than the same score in a peripheral utility. The blast radius is your entire data estate.

In India, Metabase has become the analytics backbone for dozens of fintech, healthtech, and e-commerce platforms that aggregate data on millions of Indian consumers. A single exploited instance can expose PII at a scale that triggers obligations under India’s Digital Personal Data Protection Act, 2023 (DPDPA).

Technical Breakdown: How One API Call Unlocks Your Entire Analytics Stack

The flaw resides in Metabase’s password-reset handler at /api/session/reset_password. Under normal circumstances, this endpoint accepts a token and a new password. The vulnerability allows an attacker to embed arbitrary SQL inside the token parameter, which Metabase passes unsanitised into a database query — a textbook second-order SQL injection in a path that was never expected to carry executable payload.

The attack sequence:

1. Attacker sends a crafted POST /api/session/reset_password request with malicious SQL in the token field.
2. The injected query promotes a chosen user (or a newly created one) to administrator within Metabase’s internal database.
3. The endpoint returns HTTP 400 — appearing to fail — while the SQL has already executed.
4. A follow-up GET /api/user/current returns HTTP 200 with administrator-level session context.
5. The attacker now has full admin access: they can browse saved questions, dashboards, database connections — and extract the plaintext connection strings stored in Metabase settings.

The two-step IOC pattern — POST /api/session/reset_password → 400 followed by GET /api/user/current → 200 — is the clearest hunting rule you can write today. If these two calls appear in sequence from the same source IP in your Metabase access logs, assume breach.

Detail	Value
Advisory ID	GHSA-vwf4-m7j8-wcjf
CVE	Not yet assigned
CVSS Score	10.0 (Critical)
Attack Vector	Network — unauthenticated
Vulnerable Endpoint	/api/session/reset_password
Affected Versions	0.58.0 – 0.63.4
First Exploitation Observed	3 August 2026
Patch Released	7 August 2026
Fixed Versions	0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5

Confirmed Victims: What Was Taken

Framework, the right-to-repair laptop company whose customer base skews technical and privacy-conscious, disclosed on 8 August that attackers accessed customer names, login IP addresses, billing and shipping addresses, and e-mail addresses. Payment and order data was not in Metabase’s scope and was not exposed. Framework confirmed the attack occurred on 3 August — four days before Metabase published patches — making this a true zero-day exploitation window.

Tally, the popular web-based form builder used by hundreds of thousands of creators and businesses to collect data, confirmed that attackers obtained e-mail addresses and password hashes for customer accounts. Hashed passwords are not plaintext, but if those hashes are weak (bcrypt with low work factor, or worse, MD5/SHA-1), cracking them is now a realistic downstream risk. Tally users who reuse passwords elsewhere should rotate them immediately.

LexisNexis disclosed that its Metabase API was impacted. The full scope of data exposure has not been confirmed publicly as of publication. For a firm that holds legal research, court records, and due-diligence data on millions of individuals and entities, even a partial exposure carries significant compliance and legal-liability implications.

The Zero-Trust Angle: Why BI Tools Need the Same Scrutiny as Firewalls

From a zero-trust architecture standpoint, this incident illustrates a gap that many organisations have yet to close: the assumption that internal tools are implicitly trusted. Metabase instances are frequently deployed behind a VPN or corporate firewall with the reasoning that “only our people can reach it anyway.” But zero-trust explicitly rejects implicit trust based on network location — and this breach demonstrates exactly why.

Had the affected organisations applied zero-trust principles rigorously to their analytics stack, the attack surface would have been dramatically smaller:

• Identity-aware proxy in front of Metabase would have blocked the unauthenticated API call before it reached the application layer.
• Least-privilege database accounts for Metabase’s data-source connections would have limited what an attacker could exfiltrate even after gaining admin access.
• Secrets rotation for database credentials stored in Metabase would reduce the window of exposure when a breach occurs.
• Continuous monitoring (SIEM integration for application logs) would have detected the IOC pattern — the 400/200 anomaly — within minutes rather than days.

I have seen this pattern repeatedly in SOC engagements across Delhi NCR: organisations invest heavily in perimeter security (FortiGate, SD-WAN, next-gen firewalls) but leave analytics platforms, internal dashboards, and developer tools exposed on flat internal networks. An attacker who lands on that network — via phishing, a supply-chain compromise, or a stolen VPN credential — finds rich targets with no inner-ring defences. That gap is exactly what the Metabase attackers exploited. For more context on how supply-chain and third-party tool compromises bridge the outer perimeter, see my earlier coverage of the npm Shai-Hulud worm and the Langflow AI platform RCE.

What You Should Do Right Now

This is not a “patch in the next maintenance window” situation. Exploitation is confirmed and the attack is trivially simple. Take the following actions in order:

1. Identify all Metabase instances — include shadow IT. Ask your DevOps, Data Engineering, and BI teams. This tool spreads organically; you likely have more instances than you think.
2. Immediately block /api/session/reset_password at your WAF, reverse proxy (nginx, Caddy, Apache), or FortiGate application control policy. This is your emergency brake — it prevents new exploitation while you schedule upgrades.
3. Upgrade to a fixed version: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5. Check the official Metabase security advisory GHSA-vwf4-m7j8-wcjf for your branch.
4. Rotate all database credentials stored in Metabase’s data-source configurations — even on patched instances. Assume attackers had time to read them.
5. Revoke all active Metabase sessions and force re-authentication. API keys associated with service accounts should also be rotated.
6. Audit administrator accounts in Metabase. Look for accounts you do not recognise, recently promoted accounts, or accounts with unusual API key issuance dates.
7. Hunt the IOC in your logs: search for POST /api/session/reset_password returning 400 followed immediately by GET /api/user/current returning 200 from the same IP. If found, treat as confirmed breach and invoke your incident response plan.
8. Check downstream databases. If Metabase credentials were exposed, an attacker may have already connected to your data warehouse, RDS instance, or BigQuery project and exfiltrated data. Review access logs on connected databases for unexpected queries or large exports in the 3–8 August window.

If you use Metabase Cloud, your instance was patched automatically. Your priority is still to rotate database credentials as a precaution, since you cannot rule out pre-patch access.

For organisations with FortiGate or FortiADC deployed in front of web applications, creating a local WAF policy to block POST requests to the exact URI path /api/session/reset_password is a five-minute configuration that eliminates the attack surface entirely until patching is complete. Reach out if you need a walk-through — this is exactly the kind of layered defence that Fortinet’s application-layer controls are designed for.

Frequently Asked Questions

Is Metabase Cloud affected?

No. Metabase Cloud instances were patched automatically. If you use Metabase Cloud, you do not need to apply a manual upgrade — but you should still rotate database credentials stored in your data sources as a precautionary measure, and you should verify your audit logs for any anomalous access in the 3–7 August window.

No CVE has been assigned — does that mean it is less serious?

Absolutely not. The absence of a CVE number means many automated vulnerability scanners will not flag this flaw yet, which actually makes it more dangerous in practice — your vulnerability management tooling may give you false confidence. The GHSA advisory (GHSA-vwf4-m7j8-wcjf) and CVSS 10.0 rating are authoritative regardless of CVE status. Act on the advisory, not the scanner alert.

My Metabase is behind a VPN — am I safe?

Safer, but not necessarily safe. If an attacker gains initial access through phishing, a compromised endpoint, or a supply-chain attack, your VPN boundary does not protect Metabase from internal exploitation. The attack requires only HTTP access to the Metabase instance — it does not need external reachability. Zero-trust segmentation, identity-aware proxies, and application-layer controls are the right answer here, not VPN perimeter alone.

How long did attackers have before patches were available?

The confirmed exploitation window is 3 August to 7 August 2026 — four days. Metabase notified Framework on 6 August, one day before publishing the patch. The gap between first exploitation and public patch availability means every self-hosted Metabase instance that was internet-reachable (or reachable by a network-adjacent attacker) should be treated as potentially compromised until an investigation says otherwise.

Final Thought: Your Analytics Platform Is Part of Your Attack Surface

The Metabase zero-day is a reminder that data tools are not exempt from security controls. Every platform that stores database credentials, processes user-controlled input, or holds sensitive analytical data belongs in your threat model and your patching pipeline. A CVSS 10.0 in your BI layer can be as damaging as one in your edge firewall — sometimes more so, because the data your BI tool can reach is often your most sensitive asset.

If you are unsure whether your organisation has unpatched Metabase instances, unmonitored analytics platforms, or gaps in your inner-ring zero-trust controls, now is the moment to find out — before an attacker does it for you.

Get a security assessment from Sanjay Seth.

Whether you need an urgent review of your analytics and data tool exposure, a zero-trust architecture gap analysis, or a hands-on incident response engagement, P J Networks is ready to help organisations across India act before a breach — not after.

Book a Security Consultation →

Sources: Metabase Security Advisory GHSA-vwf4-m7j8-wcjf · BleepingComputer · The Hacker News · Security Affairs · Rapid7 Threat Intelligence