Unauthenticated SQL injection in the Metabase password-reset endpoint enables administrator access

Metabase allows a remote, unauthenticated attacker to inject arbitrary SQL via the '/reset_password' database endpoint and gain administrator access to the connected Metabase instance.

The following Metabase ranges are identified as affected:

• Metabase x.58.0 through less than x.58.24; the corresponding fixed release is x.58.24.
• Metabase x.59.0 through less than x.59.21; the corresponding fixed release is x.59.21.
• Metabase x.60.0 through less than x.60.17; the corresponding fixed release is x.60.17.
• Metabase x.61.0 through less than x.61.11; the corresponding fixed release is x.61.11.
• Metabase x.62.0 through less than x.62.9; the corresponding fixed release is x.62.9.
• Metabase x.63.0 through less than x.63.5; the corresponding fixed release is x.63.5.

Metabase states that its Cloud instances were upgraded and patched. Self-hosted deployments should be checked against the actual release branch in use; the status of branches not listed in the record is unknown.

Metabase contains a CWE-89 SQL injection in its password-reset flow, where attacker-controlled data can be interpreted as SQL rather than ordinary input. The vendor identifies the relevant route as /api/session/reset_password; the normalized description refers to it as /reset_password. A remote attacker can reach the endpoint over the network without authentication or user interaction and affect the Metabase application database. Successful exploitation can lead to administrator access to the Metabase instance, which may then allow configuration changes, access to stored credentials for connected databases, and access to data permitted by those connections. The available evidence does not establish the exact SQL construction, query-building path, or specific database engine involved.

The vulnerability is remotely reachable over the network and does not require authentication, prior privileges, or user interaction. The supplied record marks it as exploited and reports a public exploit; Metabase also confirmed active exploitation. Metabase stated that its Cloud instances were upgraded and patched, while self-hosted deployments require separate verification. The available evidence does not identify an actor, campaign, victim, or exploit procedure for this entry.

The direct technical result is unauthorized SQL execution against the Metabase application database, with a possible transition to administrator access on the instance. That access may allow changes to application configuration, accounts, or sessions, and may expose database credentials stored by the application. Access to connected databases is conditional on the permissions of those credentials and the deployment configuration, but it can extend the impact from Metabase to enterprise data. Realistic consequences include loss of confidentiality, unauthorized changes to data or configuration, and service disruption. The available evidence does not establish host-level code execution, container escape, or access beyond the permissions of the connected databases.

The vulnerability can turn an unauthenticated endpoint into an entry point for administrative control of Metabase.

• An attacker may change application configuration and administrative settings.
• Credentials stored for connected databases may be exposed, potentially enabling access to data permitted by those connections.
• Data may be read, exported, or modified depending on database permissions and instance configuration.
• Changes to configuration or administrative data may affect service availability and trust in analytics results.

The record does not establish that a particular organization experienced data loss, service interruption, or compromise.

1. Upgrade Metabase to the fixed release for the branch in use:

• x.58 branch: upgrade to x.58.24.
• x.59 branch: upgrade to x.59.21.
• x.60 branch: upgrade to x.60.17.
• x.61 branch: upgrade to x.61.11.
• x.62 branch: upgrade to x.62.9.
• x.63 branch: upgrade to x.63.5.

1. If an immediate upgrade is not possible, temporarily block access to /api/session/reset_password at the reverse proxy, load balancer, or ingress layer. This is a temporary mitigation and does not replace the patch.
2. If the endpoint was publicly reachable, revoke all active user sessions after upgrading by deleting rows from the core_session table, review and remove unrecognized API keys, and check administrator accounts for unexpected changes.
3. Rotate credentials for every database connected to Metabase, then review data warehouse logs, Metabase activity, and query history for unauthorized access.
4. If exploitation is suspected, preserve relevant logs and follow the organization's incident response process rather than relying on the upgrade alone.

Use the following checks to assess exposure and possible compromise:

1. Inventory self-hosted Metabase instances, verify their release branches, and compare them with the affected ranges in affected_summary.
2. Determine whether /api/session/reset_password is publicly reachable through a reverse proxy, load balancer, or ingress layer.
3. Search application or ingress logs for a suspicious sequence consisting of POST /api/session/reset_password returning 400, followed by GET /api/user/current returning 200. Metabase says this pattern may indicate compromise.
4. Review sessions, API keys, administrator accounts, activity history, and query history for unexpected changes or unauthorized activity.
5. Correlate application database and data warehouse logs for unusual access, and review whether credentials for connected databases need to be rotated.

The absence of this log pattern does not prove that an instance is safe because logging may be incomplete or unavailable.