Metabase reset_password SQL injection exposes self-hosted deployments

At a glance

What this is: A critical SQL injection in Metabase’s unauthenticated password reset endpoint can let attackers run arbitrary SQL and take over affected self-hosted deployments.

Why it matters: It matters because compromise of an analytics platform can become an identity and privilege problem, exposing admin access, stored secrets, and downstream databases.

By the numbers:

• The flaw carries a CVSS v3.1 score of 10.0 (Critical) - AV:N, AC:L, PR:N, UI:N, S:C, C:H, I:H, A:H - meaning exploitation requires no authentication, no user interaction, and only low attack complexity.
• Metabase 58: 58.24 or later; Metabase 59: 59.21 or later; Metabase 60: 60.17 or later; Metabase 61: 61.11 or later; Metabase 62: 62.9 or later; Metabase 63: 63.5 or later.

👉 Read Bishop Fox's analysis of the Metabase password reset SQL injection

Context

Metabase SQL injection in an unauthenticated password reset flow is a governance failure as much as a vulnerability. When user-supplied fields can influence database queries, the application boundary stops behaving like a controlled trust zone and starts acting like an external attack surface, especially in self-hosted analytics systems that sit close to sensitive data and credentials.

For identity and access teams, the practical concern is not only application compromise but privilege amplification. A successful exploit can alter admin state, access secrets held by the application, and open a path into connected databases, which turns a single web endpoint into a broader access-control incident rather than a narrow app bug.

This pattern is not atypical for exposed self-hosted services that combine unauthenticated workflows with backend data access.

Key questions

Q: What breaks when unauthenticated application workflows accept unexpected fields?

A: Unexpected fields can slip into query construction, turn user input into executable logic, and bypass the intended trust boundary of the workflow. In practice, that means a password reset or onboarding endpoint can become a database access path. The right control is strict field validation, least-privilege backend access, and separation between identity recovery and data query functions.

Q: Why do internet-facing recovery endpoints create disproportionate risk?

A: Because they often combine no-auth access with backend privileges, giving attackers a direct path to high-value systems if input handling fails. A single flaw can expose admin state, connected databases, or runtime secrets. Security teams should classify these endpoints as control-plane surfaces and apply stronger validation, logging, and privilege isolation than ordinary web forms.

Q: How do security teams know when a self-hosted analytics platform has become a privilege exposure point?

A: Look for platforms that hold database credentials, can create or change administrators, or can reach multiple downstream data sources with one service account. Those are signs the platform can amplify compromise beyond its own boundary. If compromise would let an attacker pivot into connected systems, the platform is already acting like a privileged intermediary.

Q: Who is accountable when a vulnerable self-hosted service exposes connected databases?

A: Accountability usually spans application owners, platform operators, and the team responsible for service privilege design. If the service can reach secrets or downstream databases, the owning team must treat it as a privileged integration rather than a standalone app. Frameworks such as NIST SP 800-53 and Zero Trust principles both push responsibility toward access minimisation and monitored trust boundaries.

Technical breakdown

How undeclared request fields become SQL injection input

The core failure is in request handling, not in authentication alone. The password reset endpoint accepts a body that should contain only a narrow set of fields, but undeclared fields were able to flow into the query-building path. When application code treats structured input as if it were a validated identifier, the database layer may interpret it as executable SQL rather than inert data. In this case, the reset workflow becomes a direct query construction channel exposed to the internet.

Practical implication: validate and whitelist every field accepted by unauthenticated workflows before those fields reach query builders.

Why unauthenticated endpoints create disproportionate blast radius

An unauthenticated endpoint removes the normal control points that would otherwise reduce exposure, such as identity verification, rate limiting tied to accounts, and privilege-based query separation. If the endpoint also reaches a privileged application database, then a single malicious request can execute with the application’s own authority. That is why unauthenticated does not mean low risk. In systems like Metabase, the application often sits near other high-value credentials, so initial compromise can pivot into additional systems if secrets are available to the runtime.

Practical implication: segment backend privileges so internet-facing workflows never inherit broad database or secrets access.

How compromise of an analytics platform can become data and identity exposure

Once an attacker can alter application records or gain administrative access, the issue extends beyond application integrity. Admin changes can redirect reset flows, expose stored credentials, and alter connections to downstream databases or warehouses. That creates a hybrid risk pattern where an application flaw turns into both identity compromise and data access expansion. The important lesson is that analytics platforms are often privileged intermediaries, not isolated tools, and therefore need the same scrutiny as other control-plane systems.

Practical implication: treat analytics platforms as privileged access nodes and monitor them like control-plane services.

Threat narrative

Attacker objective: The attacker seeks administrative control of Metabase and a pivot into the databases, secrets, and data sources connected to it.

1. Entry occurs through the unauthenticated POST /api/session/reset_password endpoint, where crafted input can reach the query-building path without any login or user interaction.
2. Credential or privilege escalation follows when the attacker uses SQL injection to alter application-database records or obtain administrative access inside Metabase.
3. Impact can include access to connected databases, exposed secrets available to the runtime, and possible availability disruption of the deployment.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated SQL injection in a control-plane workflow is an access-governance failure, not just a web bug. When an internet-facing reset function can influence backend queries, the trust boundary between identity validation and data access has collapsed. That means the security model has to treat request validation, application privilege, and backend exposure as one control chain, not separate concerns. Practitioners should assume that any unauthenticated path reaching a privileged datastore can become a governance incident.

Privilege concentration in analytics platforms creates the same kind of blast-radius problem seen in NHI abuse. Metabase commonly sits close to database credentials and operational data, which makes it behave like a high-value intermediary. If that intermediary is compromised, the attacker inherits the platform’s own access rights and the scope of every connection it maintains. The practitioner lesson is to reduce standing access and isolate the privileges that analytics services need to function.

Request-validation drift is a named control gap here: undeclared-field trust. The vulnerable pattern is allowing unexpected request fields to survive into query construction. That is a governance assumption failure because the application assumes everything in the body is safe enough to interpret. Security teams should look for the same failure mode anywhere a reset, onboarding, or recovery workflow transforms user input into database logic.

Connected-system exposure is what makes this class of flaw materially worse than a single-instance compromise. The article’s own warning is that a compromised Metabase instance can become a springboard into databases and warehouses it can reach. That is a Zero Trust lesson for identity teams as much as for app teams: every service account and integration token must be constrained to the minimum path needed, or the application becomes an access broker for attackers.

Control-plane services need lifecycle controls comparable to NHI governance. Even though this incident is application security, the downstream risk is privileged machine access through stored credentials, service connections, and runtime secrets. The boundary between app compromise and identity compromise is thin when services are allowed to retain broad backend trust. Practitioners should design for short-lived, tightly scoped service access and verify that recovery endpoints cannot alter privilege state without explicit authorization.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• If a compromised analytics service can reach stored credentials, the exposure pattern is consistent with Ultimate Guide to NHIs, Why NHI Security Matters Now, which shows why machine-access paths need explicit lifecycle controls.

What this signals

A critical analytics-platform flaw is a reminder that control-plane software often inherits far more trust than its visible user interface suggests. For practitioners, the immediate question is whether any self-hosted service can reach secrets, rotate credentials, or change administrative state without a compensating control around those paths.

Undeclared-field trust: this is the failure mode to watch across recovery, enrollment, and support workflows. If a web form can still influence database logic after input validation, then application security and identity governance have both failed at the same boundary. Teams should pair application hardening with machine-identity scoping, using the Ultimate Guide to NHIs as the baseline reference for privilege and secrets exposure.

The broader programme signal is that connected-data platforms need to be monitored like privileged integration points, not treated as passive dashboards. Where service accounts, warehouse credentials, or admin reset flows exist, the exposure profile belongs in access review, secrets inventory, and incident response runbooks, alongside the rest of the identity stack.

For practitioners

• Harden unauthenticated recovery workflows Review every unauthenticated reset, invite, and onboarding endpoint for undeclared-field handling, then enforce strict request-body whitelisting before any database lookup or query construction occurs.
• Reduce backend privilege for analytics services Strip analytics platforms of broad database rights, separate read paths from admin paths, and ensure application accounts cannot modify schema, credentials, or access controls unless explicitly required.
• Audit for post-exploitation privilege changes Check administrator creation, email changes, password resets, and new data connections in Metabase activity logs, reverse-proxy logs, application-database logs, and warehouse logs.
• Treat exposed self-hosted instances as internet-facing control points Inventory every self-hosted deployment, confirm the patched branch is in place, and place alerting around any endpoint that can reach secrets or connected databases.

Key takeaways

• The vulnerability shows how a single unauthenticated workflow can become a privileged database access path when request validation is too permissive.
• The impact is larger than one application because analytics platforms often hold credentials and reach connected databases that attackers can pivot into.
• The limiting control is strict input whitelisting combined with reduced backend privilege, segmented service access, and monitoring for post-exploitation admin changes.

Key terms

• Unauthenticated SQL Injection: An unauthenticated SQL injection is a flaw that lets an external attacker alter database queries without logging in. It usually appears where application code accepts user input and passes it into query-building logic without strict validation or parameterization.
• Privileged Intermediary: A privileged intermediary is a service that sits between users and downstream systems while holding enough access to amplify compromise. Analytics platforms, automation services, and integration hubs often fit this pattern because they can reach multiple databases, credentials, or administrative functions.
• Declared Field Whitelisting: Declared field whitelisting is the practice of accepting only explicitly expected request fields and rejecting everything else. It is a defensive control for preventing hidden or unexpected input from being interpreted as query logic, configuration data, or privilege-changing instructions.
• Control-Plane Workflow: A control-plane workflow is a process that changes identity state, access state, or system configuration rather than just displaying data. Password resets, account provisioning, and administrative changes belong here, and failures in these paths tend to have wider consequences than ordinary application bugs.

What's in the full analysis

Bishop Fox's full post covers the operational detail this post intentionally leaves for the source:

• Patch-level guidance for the affected Metabase branches, including version-specific upgrade targets.
• Response timeline details showing how the threat was reverse engineered, fingerprinted, and validated in live environments.
• Log sources and indicators the vendor used to confirm exploitation and assess customer exposure.
• Practical remediation steps for admins who need to verify whether undeclared fields can still influence backend queries.

👉 Bishop Fox's full post covers the exploit path, affected versions, and immediate defensive steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect service access, privilege scope, and remediation discipline across identity programmes.