Critical Metabase Zero-Day Exploited

Metabase has disclosed a critical zero-day SQL injection (SQLi) vulnerability that can allow unauthenticated attackers to gain administrator access to vulnerable instances. The flaw is rated at maximum severity, and the vendor has confirmed active exploitation.

The risk is highest for self-hosted deployments, especially instances exposed to the internet. Successful exploitation of the Metabase zero-day can let attackers change configuration, access stored credentials for connected databases, read data available through those connections, and export data.

What Is the Metabase Zero-Day?

It is an SQL injection vulnerability affecting an unauthenticated endpoint. Metabase published its advisory on August 6, 2026, rated the issue Critical, and assigned it maximum severity (CVSS 10.0). No CVE identifier had been assigned at the time of disclosure.

The key issue is the trust boundary. An attacker does not need a valid Metabase account before attempting exploitation. If a crafted request reaches a vulnerable instance, attacker-controlled input may affect the Metabase application database and lead to administrative control.

That makes this more serious than a narrow query manipulation bug. Administrator access to Metabase can expose application settings, sessions, API keys, stored database credentials, query history, dashboards, and data reachable through configured database connections.

Which Metabase Versions Are Affected?

Metabase lists affected versions across the x.58 through x.63 release branches. Self-hosted operators should upgrade to the fixed release that matches their branch.

The advisory does not confirm whether versions older than x.58 are affected. Organizations running older or unsupported deployments should verify exposure directly and avoid assuming legacy versions are safe without vendor guidance.

Which Metabase Endpoint Is Vulnerable?

Metabase identifies /api/session/reset_password as the relevant endpoint for mitigation. The vendor recommends temporarily blocking this endpoint when immediate upgrading is not possible.

This matters because the endpoint is unauthenticated. A publicly reachable Metabase instance may receive exploit attempts before an attacker has any account or session. That exposure makes internet-facing self-hosted deployments the first priority for response.

How Could the Metabase SQL Injection Be Exploited?

At a high level, an attacker can send a crafted request to the vulnerable password reset endpoint of an exposed, unpatched Metabase instance. The flaw can allow SQL injection into the Metabase application database, which may then lead to administrator access.

Metabase has not publicly disclosed the exact vulnerable parameter, payload structure, database engine dependency, or code level defect. Defenders do not need those details to act. The key risk is that an unauthenticated web request can become a path to administrative control of the application.

After compromise, an attacker may be able to:

• Modify Metabase application settings
• Create or alter administrator accounts
• Access stored database credentials
• Review query history and dashboards
• Use configured database connections to read or export data
• Generate or abuse API keys
• Inspect connected data sources

Available vendor guidance supports administrative compromise and data access as the main impact. It does not confirm automatic operating-system compromise or arbitrary code execution on the Metabase host.

Is the Metabase Zero-Day Actively Exploited?

Yes. Metabase states that it has confirmed active exploitation and urges customers to upgrade as soon as possible.

Confirmed exploitation changes the response priority. Self-hosted operators should not wait for a CVE assignment, public proof-of-concept (PoC) code, or additional reporting before patching and investigating exposed instances.

What Detection Signals Did Metabase Provide?

Metabase provided one behavioral indicator that may suggest compromise:

A POST request to /api/session/reset_password returning HTTP 400, followed by a successful GET request to /api/user/current returning HTTP 200. This sequence should be reviewed in reverse-proxy logs, Metabase logs, and network telemetry.

Security teams should also check for:

• Unexpected administrator account additions or changes
• Unrecognized API keys
• Suspicious active sessions
• Unusual query history or bulk exports
• Database access inconsistent with normal reporting
• Unexpected application configuration changes
• Outbound transfers from Metabase hosts or connected data services

Metabase has not published stable attacker IP addresses, user agent strings, payloads, hashes, or a complete forensic signature set. Version validation and behavior based investigation should come first.

What Should Defenders Do Now?

1. Patch Self-Hosted Metabase Immediately

Upgrade every self-hosted Metabase installation to the fixed release for its branch:

• x.58.24
• x.59.21
• x.60.17
• x.61.11
• x.62.9
• x.63.5

2. Block the Endpoint if Patching Is Delayed

If immediate patching is not possible, temporarily block external access to /api/session/reset_password. This is only a temporary risk reduction step and should not replace upgrading.

3. Revoke Sessions and Review Access

For publicly accessible instances, Metabase recommends revoking active sessions by deleting all rows from the core_session table. Teams should also review API keys, check administrator accounts, and remove anything unfamiliar.

4. Rotate Connected Database Credentials

Metabase recommends rotating credentials for every connected database and reviewing warehouse logs for unauthorized access. This step is critical because a compromised Metabase instance may expose data through the permissions granted to connected database accounts.

5. Review Query and Activity History

Review Metabase activity logs, query history, bulk exports, and database access patterns. For exposed deployments, treat suspicious endpoint activity as a potential incident until administrative access, sessions, API keys, and connected database activity are validated.

How Can SOCRadar Help Prioritize Response?

For this Metabase zero-day, combining vulnerability intelligence with exposure visibility helps teams identify publicly reachable Metabase instances, confirm patch status, and prioritize systems connected to sensitive databases.

To support this effort, SOCRadar’s Cyber Threat Intelligence enables teams to track critical updates, exploit alerts, and attacker interest as new issues emerge. This ensures security professionals can move quickly when a confirmed zero-day becomes an active remediation priority.

Furthermore, the Attack Surface Management (ASM) module provides essential exposure context by identifying internet-facing services, DNS records, and undiscovered cloud assets. By cross referencing critical vulnerabilities with these exposed software assets, ASM automatically alerts teams to the most urgent risks in their infrastructure.