Metabase Zero-Day Hits CVSS 10.0: Unauthenticated SQL Injection Gives Full Admin

TL;DR - what: Metabase disclosed that an unauthenticated SQL injection flaw in its BI platform was exploited in the wild as a zero-day, letting remote attackers write to the application database and grant themselves administrator access. Metabase is telling self-hosted customers to patch now. An unauthenticated attacker can inject arbitrary SQL into the Metabase application database and promote themselves to administrator on the instance. CVSS 10.0. No CVE identifier was assigned. The vendor found the bug because someone used it against Metabase Cloud first, which makes this a confirmed in-the-wild zero-day rather than a theoretical maximum-severity rating. The blast radius is not the BI tool. It is everything the BI tool connects to. With admin on a Metabase instance, an attacker changes application configuration, extracts the stored credentials for every connected database, reads any data reachable through those connections, and exports it. Metabase sits deliberately in the middle of an organization's data warehouses, production replicas, and analytics stores, holding standing credentials to all of them. Compromising it is closer to compromising a credential vault than compromising a dashboard. What is affected Six release branches are in scope, all versions 1.58 and above. Metabase ships parallel Open Source and Enterprise version lines, which is why the advisory uses the x. prefix - substitute 0. for OSS and 1. for Enterprise builds. Every branch got its own patch release: - >= x.58.0 and = x.59.0 and = x.60.0 and = x.61.0 and = x.62.0 and = x.63.0 and < x.63.3 - fixed in x.63.5 Note the last line. The 63 branch was vulnerable below x.63.3 but the fix landed in x.63.5, not x.63.4. If your patch automation naively bumps to the first version above the vulnerable range, you will land on a build that does not contain the fix. Verify the exact target version rather than trusting a range comparison. Metabase Cloud instances have already been updated by the vendor. If you self-host - on-prem, in a container, on an EC2 instance somebody spun up for the analytics team two years ago - the patching is yours to do. ⚠️ Workaround if you cannot patch today - Block the /api/session/reset_password endpoint at your reverse proxy, WAF, or ingress. That is the vendor-recommended temporary mitigation and it is a single rule. It is a stopgap, not a fix - the endpoint block buys you a maintenance window, nothing more. Patch to the exact fixed version for your branch as soon as you can schedule it. How to tell if you were hit Metabase has not released details of the malicious activity, but it did publish a compromise indicator that is unusually easy to hunt for. Look in your Metabase application logs or your server ingress logs for this two-request sequence: - POST /api/session/reset_password returning HTTP 400 - immediately followed by GET /api/user/current returning HTTP 200 A failed password reset followed by a successful authenticated identity check is the signature of the exploit completing. In the vendor's own words, if you find that pattern, it is likely your instance has been compromised. Write the detection now and run it against retained logs, not just live traffic - the flaw was exploited before it was disclosed, so your window of interest starts well before the advisory date. Post-patch cleanup Patching does not evict an attacker who already established persistence. If your /api/session/reset_password endpoint was reachable from the internet, Metabase advises treating the instance as suspect and working through the following after the update: - Revoke all active sessions by connecting to the Metabase application database and deleting every row in the core_session table - Review all API keys and delete any you do not recognize - Audit administrator accounts for accounts or permission changes you did not make - Rotate credentials for every connected database - assume they were read - Review data warehouse logs for unauthorized access from the Metabase service account - Review Metabase activity and query history for queries nobody on your team ran The credential rotation is the step teams skip and the one that matters most. Metabase stores connection credentials so it can query on your behalf; an admin-level attacker exports them and then no longer needs Metabase at all. Rotating them is what actually closes the intrusion path into the warehouse. Confirmed downstream victim PC maker Framework has notified all of its customers that data was accessed during the incident. Exposed fields include customer names, addresses, phone numbers, email addresses, and login IP addresses. Framework says no order or payment information was accessed. That is a useful calibration of the damage profile: attackers pulled whatever the compromised Metabase instance's connections could reach, which for a retail-adjacent company means the customer table. This is a pattern, not an outlier Exactly three years ago Metabase patched CVE-2023-38646, a CVSS 9.8 pre-authentication remote code execution flaw that saw mass scanning within days of disclosure. Two maximum-tier pre-auth bugs in the same product in three years should change how you deploy it. Internal analytics tooling ends up internet-facing because someone wanted dashboards accessible from a phone, and then it inherits an attack surface it was never hardened for. Get BI tooling off the public internet - Two actions this week. First, inventory every Metabase instance you run, including the ones shadow IT stood up, and confirm each is on the exact fixed release for its branch. Second, check whether any of them are reachable without going through your VPN or identity-aware proxy. A pre-auth CVSS 10.0 in a tool that holds warehouse credentials is only a catastrophe if an unauthenticated attacker can reach the endpoint. That part is within your control today. Originally published on RedEye Threat Intelligence. Top comments (0)