Notifications
Clear all
Topic starter
14/08/2026 6:34 pm
TL;DR: A critical unauthenticated SQL injection in Metabase’s password reset flow lets attackers execute arbitrary SQL against the application database and potentially reach connected data sources, according to Bishop Fox. The issue shows how unauthenticated interfaces can become high-impact identity and access control failures when request validation is too permissive.
NHIMG editorial — based on content published by Bishop Fox: Metabase password reset SQL injection vulnerability and response guidance
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.
Questions worth separating out
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.
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: Look for platforms that hold database credentials, can create or change administrators, or can reach multiple downstream data sources with one service account.
Practitioner guidance
- 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.
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.
👉 Read Bishop Fox's analysis of the Metabase password reset SQL injection →
Metabase SQL injection in password reset: are your controls ready?
Explore further
14/08/2026 6:42 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Metabase reset_password SQL injection exposes self-hosted deployments
