Metabase users should treat the latest security warning as urgent. The business intelligence and data visualization platform has disclosed a maximum-severity vulnerability that was exploited as a zero-day and can allow remote, unauthenticated attackers to reach administrator-level control of a Metabase instance. Treat this as an incident-response priority, not a routine maintenance update.

The issue is especially serious because Metabase often sits close to sensitive analytics assets: application databases, data warehouses, dashboards, API keys, and stored connection credentials. A compromise of the Metabase application can therefore become a compromise of the data sources it is allowed to query.

What happened

According to reporting based on Metabase's advisory, the flaw has a CVSS score of 10.0 and did not yet have a CVE identifier at the time of publication. The vulnerability affects the Metabase application database and enables arbitrary SQL injection by an unauthenticated remote attacker. In practical terms, successful exploitation can let an attacker gain administrator access to the Metabase instance without first logging in.

Once an attacker has that level of access, the potential impact goes well beyond changing dashboard settings. An intruder may be able to alter application configuration, create or modify accounts, inspect stored credentials for connected databases, read data available through those connections, and export information. For organizations using Metabase to centralize business reporting, that can include customer records, operational metrics, financial data, or other sensitive internal datasets depending on how the deployment is configured.

Metabase said its cloud-hosted service has already been updated. The highest-risk group now is self-hosted Metabase operators, particularly internet-exposed instances and environments where the password reset endpoint is reachable from untrusted networks.

Affected and fixed versions

Administrators should compare their deployed version against the fixed release lines immediately. The affected ranges reported are:

- x.58.0 through versions before x.58.24; fixed in x.58.24
- x.59.0 through versions before x.59.21; fixed in x.59.21
- x.60.0 through versions before x.60.17; fixed in x.60.17
- x.61.0 through versions before x.61.11; fixed in x.61.11
- x.62.0 through versions before x.62.9; fixed in x.62.9
- x.63.0 through versions before x.63.5; fixed in x.63.5

If your instance is in one of these ranges, patch first and investigate second unless an emergency change process requires a parallel response. Delaying the update while collecting perfect evidence can leave the same path open for additional exploitation.

Temporary mitigation

If you cannot update immediately, Metabase recommends blocking access to the /api/session/reset_password endpoint as a temporary workaround. This should be done at the reverse proxy, load balancer, web application firewall, ingress controller, or network layer depending on how your deployment is exposed.

This mitigation should not be treated as a substitute for patching. Endpoint blocking can reduce exposure, but it may be incomplete if traffic reaches Metabase through multiple paths, if internal networks are less trusted than assumed, or if an attacker already has a foothold. Apply the vendor-fixed version as soon as possible and then keep the mitigation in place only as long as your own risk model requires.

Signs of possible compromise

Metabase shared a log pattern that may indicate exploitation. Security teams should search Metabase application logs and ingress logs for a request sequence involving a POST /api/session/reset_password returning HTTP 400, followed by a GET /api/user/current returning HTTP 200.

That pattern is not merely a generic scan indicator. Metabase's guidance says that if this sequence appears in relevant logs, it is likely the instance has been compromised. Organizations should preserve logs before rotating or rebuilding systems so responders can determine the scope of access, the accounts involved, and whether data was queried or exported.

Response checklist for defenders

After updating, assume that exposed vulnerable systems may already have been touched. At minimum, security and operations teams should:

  1. Revoke active sessions by clearing the relevant session records from the Metabase application database, following vendor guidance and tested backup procedures.
  2. Review all administrator accounts for unexpected users, role changes, or recently modified credentials.
  3. Inspect API keys and remove any that are unrecognized, stale, or no longer required.
  4. Rotate credentials for databases connected to Metabase, especially high-privilege accounts or shared service credentials.
  5. Check data warehouse, database, and Metabase query history for unusual access, large exports, new queries, or access outside normal business patterns.
  6. Review ingress, proxy, and application logs for the reset-password and current-user request pattern described above.
  7. Confirm that Metabase is not unnecessarily exposed to the public internet. Where possible, place it behind SSO, VPN, private network access, or identity-aware proxy controls.
The credential rotation step is important. Even if the vulnerable Metabase instance is patched, credentials copied before the update may remain valid elsewhere. Treat connected databases as part of the incident boundary until logs and access reviews show otherwise.

Why this matters

Business intelligence platforms are attractive targets because they aggregate access. A single reporting tool may have read paths into many datasets that would otherwise require separate permissions. Attackers understand that compromising the analytics layer can be faster than attacking each database directly.

This incident also highlights the importance of least privilege for analytics service accounts. Metabase connections should use credentials with only the access required for reporting. Avoid using database superuser accounts, broad write permissions, or shared credentials that are reused outside the BI environment. Segmentation and scoped credentials cannot prevent every application-layer exploit, but they can limit the blast radius when one occurs.

For now, the practical guidance is straightforward: identify every self-hosted Metabase instance, upgrade to the fixed version for your release line, block the vulnerable endpoint if immediate patching is delayed, rotate sensitive connected credentials, and investigate logs for the published indicators.

Source: The Hacker News source