Metabase Instances Actively Exploited: Unauthenticated Admin Takeover via BI Layer Reset Password SQL Injection (CVE-2026-72898)

Executive Summary

Upwind recently observed multiple Advanced Persistent Threat (APT) groups actively exploiting CVE-2026-72898. This vulnerability – an unauthenticated SQL injection in the Metabase password reset endpoint carrying a critical CVSS score of 10.0, was actively exploited as a zero-day before a patch became available.

An unauthenticated remote attacker can craft a malicious SQL injection request to the POST /api/session/reset_password endpoint. This injects code directly into the Metabase application database, allowing the attacker to instantly grant themselves administrative access.

Because Metabase sits directly on top of production databases and data warehouses, gaining administrative privileges effectively grants the attacker access to stored connection credentials, saved queries, and all underlying business data. While Metabase Cloud instances have already been patched by the vendor, self-hosted environments remain at severe risk.

Every self-hosted deployment running version 0.58.0 or above must be upgraded immediately. Furthermore, any instance whose reset endpoint was reachable from the internet should be treated as a potential historical compromise, requiring a full incident response investigation rather than a simple patching task.

What Is Metabase?

Metabase is an open-source business intelligence (BI) and data analytics platform designed to make data exploration accessible to non-technical users. It connects directly to production databases and data warehouses, allowing teams to query data and create interactive dashboards. Because it bridges the gap between raw database tables and business users, it requires high-level access to an organization’s most sensitive data sources.

How the Reset Password SQL Injection Works

Metabase serves as a centralized hub for sensitive database credentials, making a full compromise of the application equivalent to a breach of every connected data source. CVE-2026-72898 is an unauthenticated SQL injection that allows attackers to gain administrative access without needing to bypass passwords or SSO mechanisms.

The exploit relies on three architectural flaws within the POST /api/session/reset_password endpoint:

1. Open Request Schema: The endpoint accepts and fails to strip extra, unauthorized input fields, such as user-id, which are supplied by the attacker.
2. Unsafe State Merge: During the authentication pipeline, these extra fields are merged into the system state and remain present even if the authentication attempt fails.
3. Improper Database Handling: The database layer treats these map-based inputs as executable SQL expressions rather than scalar values. This allows the attacker to inject malicious SQL, which is executed against the internal application database with administrative privileges, granting the attacker full control.

Indicator of the POST request:

Indicator of the GET request: 

The failing assumption here was architectural rather than syntactic. The application database was treated as an internal implementation detail, leading developers to view a raw SQL fragment in that specific path as lower risk than one facing a customer’s data warehouse. In reality, the application database is the highest-value target in the entire deployment.

Active Exploitation of CVE-2026-72898

Upwind discovered active exploitation in the wild, CVE-2026-72898 initially targeted Metabase Cloud versions 1.58 and above. Metabase immediately contained the threat by blocking the affected endpoints, then identified and patched the underlying defect. Fixed point releases for all supported branches were published on Aug 6, 2026, alongside advisory GHSA-vwf4-m7j8-wcjf.

Public exploitation attempts against the unauthenticated POST /api/session/reset_password endpoint persist in the open. Attackers are utilizing time-based blind SQL injection and database-modifying payloads. Following multiple organizational disclosures of data theft and public write-ups by security vendors, the exploitation pattern is now entirely public knowledge.

The weaponization timeline has fully elapsed, leaving no reconnaissance barrier. The application is trivially fingerprintable, the vulnerable path is fixed, no authentication is required, and payloads need no per-host customization. Broad opportunistic scanning of internet-facing Metabase instances is the expected steady state.

Which Metabase Versions Are Affected?

• Metabase 0.58.0 and later are affected up to the fixed release for each branch. Fixed versions are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5, plus the corresponding 1.x Enterprise releases.
• The fix is branch-specific: for example, 0.62.5 is still vulnerable because the fix for the 0.62 branch is 0.62.9. Versions below 0.58.0 are not affected.

Indicators of Compromise (IoCs)

• The vendor’s confirmed pattern, in application or ingress logs: a POST /api/session/reset_password returning HTTP 400, followed by a GET /api/user/current returning HTTP 200. Seeing this sequence should be treated as a likely compromise rather than as a lead to evaluate.
• Repeated or bursting requests to /api/session/reset_password from a single source, with no corresponding user-initiated forgot-password activity.
• Unusually long response times on the reset endpoint, especially a cluster of responses at consistent multi-second intervals, which is the signature of time-based blind injection.
• Accounts that gained superuser or administrative group membership with no matching administrative action in the audit trail, and active sessions with no preceding successful login.
• API keys that no one recognizes, particularly any created in the same window as reset endpoint activity.
• New or changed database connection entries, and queries against connected databases from an account with no history of running them.
• Query and export activity that is anomalous in volume or target, particularly broad selects against tables an interactive analyst would not touch.
• The Metabase container behaving unlike an application server: spawning shells, running network or file transfer utilities, or opening outbound connections outside its normal set of database endpoints and update services.

Mitigation and Patching

1. Patch Immediately: Update to the specific fix for your branch (e.g., 0.58.24, 0.59.21). Verify your version directly in the application, not via deployment manifests.
2. Temporary Mitigation: If you cannot patch, block the /api/session/reset_password endpoint at your load balancer, firewall, or WAF.
3. Assume Compromise: If your reset endpoint was publicly reachable:

• Revoke all active sessions (clear core_session table).
• Audit and remove unrecognized API keys and administrator accounts.
• Rotate all connected database credentials. This is the most critical step to prevent further access.

4. Investigate: Scan logs for the compromise pattern: POST /api/session/reset_password (400) followed by GET /api/user/current (200). Check data warehouse logs for unauthorized queries.
5. Restrict Access: Move Metabase behind a private network or identity-aware proxy to prevent future exposure.

How Upwind Helps

• Upwind identifies the version actually running in each container at runtime, closing the gap that leaves :latest.
• Runtime context separates the instances that matter from the inventory. Upwind shows which Metabase deployments are internet-exposed, which are actively receiving traffic, and which connected databases they reach, so the priority list is the intersection of vulnerable, reachable, and in use rather than every image.
• API-layer visibility surfaces requests to /api/session/reset_password, including the failing 400 responses a status-code-driven rule would discard, and the sequence of that failure followed by an authenticated GET /api/user/current. Upwind can also inspect request bodies at that endpoint, so the injected user-id payload itself is visible rather than inferred from status codes alone.
• Runtime detection covers the post-exploitation stage independently of the injection: the container spawning a shell, running network or file transfer utilities, or opening outbound connections outside its normal set of database endpoints and update services.