Metabase Zero-Day Exploited in Wild Grants Unauthenticated Admin Access

Attackers are actively exploiting a maximum-severity zero-day vulnerability in the Metabase business intelligence platform, allowing unauthenticated remote attackers to execute arbitrary SQL commands and claim full administrative control over vulnerable instances. Assigned a maximum CVSS score of 10.0, the uncredentialed flaw impacts Metabase versions 1.58 and above. The vulnerability was discovered after threat actors weaponized it against Metabase Cloud infrastructure, and at least one high-profile customer—laptop manufacturer Framework—has already confirmed a data breach resulting from the exploit.

Active Zero-Day Exploitation and Impact

Metabase identified the security flaw after detecting active attacks directed against its managed Metabase Cloud platform. While Metabase automatically patched all cloud-hosted instances, self-hosted deployments remain exposed until administrators manually apply the security fixes released by the vendor.

Direct fallout from the zero-day has already emerged. Consumer electronics company Framework confirmed it was impacted after threat actors abused the flaw in its Metabase environment. According to Framework, the breach exposed sensitive customer details including full names, login IP addresses, physical delivery addresses, phone numbers, and email addresses. The company noted that no payment information or financial order records were compromised during the incident.

This attack comes exactly three years after Metabase moved to patch CVE-2023-38646, a CVSS 9.8 critical vulnerability that permitted pre-authentication remote code execution across exposed deployments.

Exploit Mechanics and Technical Context

The flaw is an unauthenticated SQL injection (SQLi) vulnerability located within Metabase’s session and authentication routing endpoints—specifically involving the password reset pipeline.

SQL injection occurs when untrusted user input is passed directly to an underlying database engine without proper parameterization or sanitization. In the case of this Metabase zero-day, an attacker can craft malicious HTTP requests targeting the password reset flow to inject SQL commands straight into the internal Metabase application database engine.

By manipulating the application database, the attacker bypasses standard authentication checks entirely. This allows them to forge or elevate administrative privileges, generating a valid high-privilege session without ever providing legitimate credentials.

Blast Radius: Why BI Software Is a High-Value Target

Business intelligence tools like Metabase sit at the nexus of an organization’s data infrastructure. To generate reports and interactive dashboards, Metabase requires direct connection strings and high-privilege credentials to underlying analytical databases, data warehouses, and production datastores (such as PostgreSQL, MySQL, Snowflake, or BigQuery).

When an attacker secures administrative control over a Metabase instance, the potential blast radius includes:

• Credential Theft: Metabase stores connection parameters and authentication secrets for all connected datastores. An administrator can view or extract these stored credentials, allowing attackers to pivot out of the Metabase application and directly target backend data warehouses.
• Unauthorized Data Exfiltration: Elevated access grants the attacker permission to run arbitrary queries across any database connected to the instance, reading and exporting sensitive customer, financial, or proprietary records.
• Configuration Manipulation: Attackers can modify system settings, alter authentication logic, or establish persistent access across the analytics environment.

Detection and Mandatory Remediation Steps

Organizations operating self-hosted Metabase deployments on version 1.58 or higher should treat remediation as an urgent priority.

Temporary Workaround

If patches cannot be installed immediately, block all public ingress traffic to the /api/session/reset_password endpoint using your web application firewall (WAF), API gateway, or reverse proxy.

Indicators of Compromise (IoCs)

Security teams should search reverse proxy, ingress, and Metabase application logs for the following sequential HTTP request pattern:

1. An initial HTTP request: POST /api/session/reset_password returning an HTTP 400 Bad Request status code.
2. A immediate subsequent request: GET /api/user/current returning an HTTP 200 OK status code.

As Metabase CEO Sameer Al-Sakran noted, discovering this specific status-code sequence in application logs indicates that the instance was likely compromised.

Incident Response and Containment

If the /api/session/reset_password endpoint was publicly accessible prior to applying updates, perform the following response actions:

1. Session Invalidation: Terminate all active user sessions by accessing the backend Metabase Application Database directly and deleting all rows in the core_session table.
2. Log Analysis: Audit connected data warehouse and database query logs for unusual query volumes, unexpected source IP addresses, or unauthorized data exports initiated during the exposure window.
3. Activity Audit: Review Metabase activity logs and query history for unauthorized account creation, elevated privilege changes, or suspicious schema queries.