Metabase reset_password SQL injection exposes self-hosted deployments

At a glance

What this is: Metabase's password reset endpoint contains a critical unauthenticated SQL injection that can expose the application database and, in some deployments, connected data sources.

Why it matters: IAM and security teams should treat application-level reset flows as access-control surfaces, because weak input validation can turn a basic identity workflow into a full administrative compromise path.

By the numbers:

• The flaw carries a CVSS v3.1 score of 10.0, which indicates critical severity.
• Metabase 58, 59, 60, 61, 62, and 63 branches are affected, with fixes available in 58.24, 59.21, 60.17, 61.11, 62.9, and 63.5 or later.

Context

Metabase's password reset flow is an access-control boundary, not just a convenience feature. When an unauthenticated endpoint accepts unexpected request fields and passes them into database logic, the application can turn a simple reset operation into direct query execution against its own backend.

This article sits at the intersection of application security, IAM, and privileged access risk because the compromised component often holds broad access to internal data sources. For self-hosted analytics platforms, a single unauthenticated injection point can become an administrative foothold that bypasses normal identity governance assumptions.

The issue is especially relevant to teams running customer-facing or internal self-hosted applications that broker access to sensitive systems. In those environments, the application itself effectively becomes a machine identity with standing permissions, so its input validation and privilege boundaries deserve the same scrutiny as any other high-risk credentialed service.

Key questions

Q: What breaks when an unauthenticated password reset flow allows SQL injection?

A: The reset workflow stops being a narrow identity function and becomes a database execution path. Attackers may change account records, obtain administrative access, and use the application's standing permissions to reach connected systems. The failure is not limited to login state. It becomes a trust-boundary collapse that can expose data and control planes beyond the application itself.

Q: Why does a public reset endpoint create such high risk in self-hosted applications?

A: Because public reset endpoints often sit close to account state and can reach privileged backend logic. If validation is weak, an external attacker can interact with the application as though it were trusted. In self-hosted environments, that trust can extend into databases, warehouses, and secrets that the application is already allowed to reach.

Q: What signs show that a reset flow is not enforcing its boundary correctly?

A: Unexpected request fields being accepted, query logs showing unusual parameter structure, and account changes that do not match normal user behaviour are all warning signs. If a reset operation can trigger database activity beyond simple token or password updates, the boundary is too loose and needs immediate review.

Q: Should teams treat application platforms like Metabase as credentialed services?

A: Yes. Any application that can access internal databases, warehouses, or secrets should be governed as a privileged machine identity, even if it is not part of the IAM stack. That means limiting access scope, reviewing what it can query, and assuming compromise of the application can expand into downstream systems.

Technical breakdown

How the reset_password endpoint becomes a SQL injection path

The flaw exists because the password-reset request body accepts undeclared fields that should never influence query construction. Instead of treating the reset request as a tightly bounded identity transaction, the application-database lookup can interpret attacker-supplied input as part of the SQL expression. That is classic injection behaviour: untrusted data crosses a trust boundary and is later executed by the database engine. In this case, the issue is made more dangerous because the endpoint is unauthenticated, so the attacker does not need a session or valid credentials to reach the vulnerable code path.

Practical implication: Treat unauthenticated request handlers as high-risk parsing surfaces and reject any field that is not explicitly required by the workflow.

Why database-backed identity flows can expose more than login state

Password reset logic often touches account records, email addresses, administrator flags, and token state, which makes it more sensitive than it appears. If the application that handles the reset flow also has access to downstream data sources, a compromise of that application can become a privilege amplification event. The attacker is not merely changing a password. They may be using the application's own database permissions to alter records, change administrative state, and query connected systems through the application's existing trust relationships. That is why identity workflows in application back ends need explicit input constraints and privilege separation.

Practical implication: Separate reset and account-management permissions from data-access permissions so a flaw in one workflow cannot reach unrelated systems.

What the patch changes in the request validation chain

Metabase's fix closes the issue by limiting the reset flow to the expected inputs and preventing undeclared request fields from influencing the application-database query. That is a control-plane correction as much as a code fix: it restores a hard boundary between externally supplied request data and internal query logic. The security lesson is that validation must happen before any downstream object lookup or query building occurs, especially on public endpoints. Once untrusted data becomes structured query input, the application has already lost the chance to enforce intent.

Practical implication: Add strict allow-list validation at the boundary and test that unexpected fields are rejected before any database access is attempted.

Threat narrative

Attacker objective: The attacker wants administrative control of Metabase and the ability to pivot into connected data sources using the application's trusted permissions.

1. Entry occurs through the unauthenticated POST /api/session/reset_password endpoint, which allows remote access without credentials or user interaction.
2. Credential-less request data reaches the application-database lookup as structured input, enabling SQL injection into the reset flow.
3. The attacker can alter records, obtain administrative access to Metabase, and then use the application's own permissions to access connected databases and secrets.
4. Impact can extend from account takeover to data exposure and possible service disruption, depending on the deployment's database engine and configuration.

Breaches seen in the wild

• SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890): Hard-coded credentials in SAP SQL Anywhere Monitor scored CVSS 10.0 (CVE-2025-42890); SAP removed the tool, and no exploitation was seen.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public reset flows are access-control surfaces, not convenience features. When an unauthenticated endpoint can alter authentication state, it must be governed like any other privileged interface. The Metabase flaw shows that identity workflows become exploitable when request validation and query construction are not tightly separated. Practitioners should treat account recovery paths as part of the attack surface, not the help-desk layer.

This breach reveals a trust-boundary failure, not just a coding bug. The core issue is that undeclared request fields were allowed to shape database logic inside a high-trust workflow. That is a named governance gap worth tracking: the reset-flow trust boundary collapse. Once that boundary fails, the application can be coerced into acting with its own standing privileges, which turns a single endpoint into a broader access problem.

Self-hosted analytics platforms carry machine-identity risk even when they are not traditional IAM systems. Metabase can hold credentials or access paths into downstream databases and data warehouses, so compromise of the platform becomes a machine-to-machine trust failure. That makes application identity, secret exposure, and privileged service access part of the same control conversation. Teams should govern these platforms as credentialed services with explicit blast-radius limits.

Critical severity alone is not the operative risk signal here, active exploitation is. A public, unauthenticated reset endpoint with confirmed exploitation means detection and patching have to outrun attacker discovery. This is the kind of exposure where runtime reachability, not just version inventory, determines practical risk. Security teams should focus on which exposed services can still receive unauthenticated traffic and how quickly those paths can be removed or constrained.

From our research library:

• Password-related issues can represent 10–50% of service desk calls, many of which are avoidable.

What this signals

Reset workflows deserve the same boundary testing as authentication code. A public password reset path that accepts undeclared fields can become an execution channel, so teams should model it as a high-risk input surface rather than a routine form submission. The practical question is not only whether the application authenticates users correctly, but whether it prevents untrusted data from reaching query-building logic at all.

Reset-flow trust boundary collapse: when an unauthenticated identity workflow can influence internal database logic, the application is effectively granting external users a route into privileged state changes. For practitioners, that means concentrating on input allow-lists, backend permission scope, and whether account recovery paths can reach anything beyond the intended identity transaction.

Metabase-style compromise patterns are especially dangerous when the platform already has access to downstream data stores. The blast radius is determined less by the flaw itself than by what the application is allowed to query once compromise occurs, so privilege scoping and secret inventory matter as much as patching.

For practitioners

• Patch affected Metabase branches immediately Move to the fixed releases for your branch and confirm that the vulnerable reset endpoint no longer accepts undeclared fields. Treat the upgrade as an emergency remediation task, not a routine maintenance change.
• Block and monitor the reset_password endpoint Add defensive controls at the reverse proxy or WAF layer for unauthenticated requests to /api/session/reset_password, and alert on unusual parameter shapes or repeated reset attempts.
• Validate account and privilege state after exposure Review administrator creation, privilege changes, email changes, and password resets in Metabase, then correlate those changes with application logs and backend database activity.
• Review downstream data-source access from the platform Inventory what credentials Metabase can reach, which databases or warehouses it can query, and whether those permissions are broader than the application's legitimate reporting needs.
• Test request-boundary enforcement in non-production Send malformed and undeclared fields to the reset workflow in a staging environment and verify that the application rejects them before any query is built or executed.

Key takeaways

• The vulnerability turns an unauthenticated password reset flow into a direct database abuse path, which is why the issue reaches beyond simple account recovery.
• Bishop Fox reports a CVSS 10.0 rating and confirmed exploitation, so exposure should be treated as immediate and operational, not theoretical.
• The control that matters most is strict request validation at the boundary, paired with reduced backend privilege for any application that brokers sensitive access.

Key terms

• SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
• Unauthenticated Management Endpoint: A service interface that allows operational actions without verifying identity first. In practice, this is a privileged path exposed as if it were public. When such an endpoint can create files, change state, or reach internal systems, it becomes a direct control-plane risk rather than a simple application bug.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners map identity boundaries to the systems and services that actually hold access in production.