<- ALL CYBER NEWS
Critical
Metabase, Zero-Day, SQL Injection, Business Intelligence, Actively Exploited

Metabase Zero-Day: Unauth SQL Injection, CVSS 10.0
A Metabase zero-day (CVSS 10.0, no CVE) is exploited in the wild for unauthenticated admin takeover. Affected versions, fixes, and workaround.
Metabase Zero-Day: Unauthenticated SQL Injection Gives Admin, CVSS 10.0
A Metabase zero-day rated CVSS 10.0 is being exploited in the wild, letting an unauthenticated remote attacker inject arbitrary SQL into the application database and take over the instance as an administrator. The flaw carries no CVE identifier, affects self-hosted Metabase versions 1.58 and above, and is fixed in x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, and x.63.5. Metabase Cloud was already patched by the vendor; self-hosted operators should update immediately or block the /api/session/reset_password endpoint as a stopgap. Metabase disclosed that an attacker used the unknown flaw against Metabase Cloud before public disclosure, on August 8, 2026.
The reason this rates a 10.0 is what admin access to a business-intelligence tool actually unlocks. Metabase stores the connection credentials for every database it visualizes. An attacker who reaches administrator can change the application configuration, read those stored credentials, and query or export any data reachable through Metabase's own service accounts. In other words, the blast radius is not the dashboard, it is every warehouse the dashboard is wired into. That is why containment here has to include rotating the credentials for all connected data sources, not just patching the app.
There is a second, quieter lesson in the disclosure: the flaw shipped without a CVE. Security teams reacting to it kept hitting the same wall, that a signature- and CVE-based vulnerability scanner had nothing to alert on. Finding exposure meant checking self-hosted image versions directly rather than waiting for a feed to light up. A maximum-severity, actively exploited bug that your vulnerability-management dashboard never mentions is a good argument for verifying what you run rather than trusting a scanner to tell you.
What should Metabase operators do right now?
Update to a fixed release immediately: x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, or x.63.5, matching your major version. If you cannot upgrade the container instantly, block access to /api/session/reset_password at your proxy or WAF as a stopgap, treating it as defense-in-depth that buys time rather than a substitute for the patch. Because exploitation targets that reset-password path, treat any instance that exposed it publicly as suspect: revoke active sessions by clearing the session table in the Metabase application database, then rotate the passwords and API keys for every connected data source. Audit ingress logs for requests to /api/session/reset_password and review your user table for unexpected admin accounts or freshly minted API keys.
Is Metabase Cloud affected?
Metabase Cloud was in fact the instance attacked before disclosure, but Metabase updated Cloud to the fixed version itself, so managed customers do not need to act. The ongoing patch responsibility falls on self-hosted deployments running 1.58 or later, which is exactly the population that has to track its own patch level. If you run Metabase yourself, assume you are in scope until you have both patched and hunted for the indicators above.
Detail | Value |
|---|---|
Vulnerability | Unauthenticated SQL injection to admin takeover |
Severity | CVSS 10.0 (no CVE assigned) |
Status | Exploited in the wild as a zero-day |
Affected | Self-hosted Metabase 1.58 and above |
Fixed in | x.58.24, x.59.21, x.60.17, x.61.11, x.62.9, x.63.5 |
Workaround | Block |
Cloud | Already patched by vendor |
Our read
Understanding risk means not outsourcing it to a CVE feed. This is a maximum-severity, in-the-wild zero-day with no identifier for a scanner to match, which is precisely the class of exposure that slips past compliance dashboards built on "any critical CVEs open?" Our review of 2025's actively exploited vulnerabilities found that 20% were exploited on or before the day they were disclosed, and a no-CVE zero-day is the extreme version of that timeline. The durable posture is to inventory and verify the software you actually run, treat any internet-reachable admin surface as a priority, and assume that "no CVE" means "no warning," not "no risk." Patch, rotate every connected credential, and hunt the reset-password path.
Reporting by The Hacker News; severity, affected versions, and remediation per Metabase's security advisory. Sources linked above.
Related: JetBrains TeamCity CVE-2026-63077 under active exploitation · Windmill CVE-2026-29059 file-read exploited in the wild