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.
Editorial analysis by NHI Mgmt Group, based on content published by Bishop Fox: “Critical SQL Injection in Metabase via Password Reset: CVE-2026-72898”.
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.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
Bottom line: The vulnerability turns an unauthenticated password reset flow into a direct database abuse path, which is why the issue reaches beyond simple account recovery.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:42 pm
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.
A few things that frame the scale:
- Password-related issues can represent 10–50% of service desk calls, many of which are avoidable.
A question worth separating out:
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.
👉 Read our full editorial: Metabase reset_password SQL injection exposes self-hosted deployments