CVE-2026-72898: Unauthenticated Metabase SQL Injection Being Exploited Now
A CVSS 10.0 flaw in Metabase's password reset endpoint lets an attacker with no credentials inject SQL, take over the admin account, and reach every database Metabase is connected to. CISA KEV listed, confirmed exploited in the wild.
Proactive Security for the AI Era
NodeZero continuously and autonomously pentests infrastructure, identity, cloud, and now web applications, chaining weaknesses across every domain the way real attackers do. Every finding ships with replayable proof showing exploitable business impact, not theoretical risk.
Metabase is a business intelligence and dashboard tool that a large share of its user base deploys internet-facing on purpose, so that embedded dashboards and shared reports can be viewed without every viewer holding a login. CVE-2026-72898 turns that deliberate exposure into a direct path to full administrative compromise: an attacker who has never authenticated to the instance can send a single crafted request to the password reset endpoint and inject SQL straight into Metabase's application database. Metabase itself confirmed exploitation against its own Cloud environment on 2026-08-06 before this advisory was public, and CISA has since added the flaw to its Known Exploited Vulnerabilities catalog, which means US federal civilian agencies are on a mandated remediation clock and every other organization should treat active exploitation as a certainty rather than a possibility.
The part of this vulnerability that raises the stakes past a typical application SQL injection is what Metabase is for. It is a dashboarding layer that most organizations wire directly to production databases, data warehouses, and analytics stores, and it holds live, working credentials for every one of those backends so it can run the queries behind its dashboards. An attacker who takes over the Metabase admin account does not just get Metabase. They get whatever Metabase was already trusted to read.
What CVE-2026-72898 actually is
The vulnerability lives in Metabase's /api/session/reset_password endpoint. Password reset flows normally accept only a token and a new password, and the backend is expected to reject anything outside that shape. Metabase's implementation instead let additional, undeclared fields in the request body reach the application's user-lookup logic as structured input rather than as a validated identifier. An attacker who understands the field Metabase actually consumes internally can supply a value there that gets interpreted as SQL rather than as data, with no session cookie, no API key, and no prior account required.
Because the injection point sits ahead of any authentication check, this is a pre-auth vulnerability in the strictest sense: the attacker's first request to the instance can be the exploit. Successful injection can manipulate authentication-related records to hand the attacker an administrator session, at which point they hold full control over the Metabase instance itself, not just a data leak from one query.
Affected products and versions
The flaw affects Metabase Open Source and Enterprise Edition. Per the internal action data compiled for this advisory, both editions in the 0.58/1.58 through 0.63.4/1.63.4 line are vulnerable prior to patching. Metabase's own advisory (GHSA-vwf4-m7j8-wcjf) specifies the fixed releases by branch:
- Metabase 58: patched in 58.24 or later
- Metabase 59: patched in 59.21 or later
- Metabase 60: patched in 60.17 or later
- Metabase 61: patched in 61.11 or later
- Metabase 62: patched in 62.9 or later
- Metabase 63: patched in 63.5 or later
Both self-hosted deployments and older Metabase Cloud instances that had not yet received the platform-side fix are in scope. If your instance's version does not match or exceed the fixed build for its branch, it is vulnerable regardless of whether it sits behind a login page for normal users, since the exploitable endpoint is reachable before login.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Exploitation status
This is not a theoretical or lab-only finding. Metabase disclosed that it identified exploitation against its own Cloud environment on 2026-08-06, ahead of public advisory release, and CISA has since listed CVE-2026-72898 in its Known Exploited Vulnerabilities catalog with exploited: true. Given that the exploit is a single unauthenticated HTTP POST with no dependency on social engineering, credential theft, or a foothold elsewhere, the barrier to mass scanning and opportunistic exploitation is low, similar in shape to other unauthenticated pre-auth SQL injection flaws in internet-facing applications that have driven mass compromise campaigns before.
Detection: the reset_password request pattern to alert on
The confirmed exploitation mechanism runs through POST requests to /api/session/reset_password that carry extra, undeclared fields in the request body. Legitimate password reset requests only ever include the documented token and password fields, so the presence of additional body fields on that specific endpoint is the reliable signal, not a generic SQL-injection keyword match against arbitrary Metabase traffic.
Why EDR and endpoint telemetry will not catch this
CVE-2026-72898 is a database-layer SQL injection reached through an HTTP request, not a process-creation, file-write, or memory-corruption event on the Metabase host. Endpoint detection and response tooling has no distinctive artifact to key on here: CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, and Cortex XDR all lack a process or file signature for this exploitation path, because the malicious input never leaves the HTTP request and the application's own query layer. Metabase's access logs forwarded to a SIEM, not the endpoint agent on the box, are where this exploitation attempt becomes visible. Teams that already run SOC alert triage workflows built around EDR-first alerting should confirm Metabase web logs are actually flowing into that pipeline before assuming coverage exists.
Validation and hunting for prior compromise
Because Metabase disclosed exploitation against its own environment on 2026-08-06, before this advisory was public, organizations should not assume the exposure window starts today. Run a retrospective sweep across your full log retention window for the same request pattern, not just forward-looking detection, since an attacker who succeeded weeks ago and did nothing further with the admin session is easy to miss without a historical pass.
Subscribe to unlock Sigma Detection Rules
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Subscribe to unlock Sigma Hunt Queries
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Mitigation while patching completes
Patching to the fixed release for your branch is the only fix for the SQL injection itself. Where an immediate upgrade cannot happen in the same maintenance window, a WAF rule in front of Metabase's query and dashboard-serving endpoints adds a layer of compensating coverage while the patch rolls out, though it does not substitute for it.
Restrict network exposure of the Metabase admin interface where the dashboard use case allows it
If the only requirement is viewing pre-built embedded dashboards, consider placing the login and admin paths behind an allowlist or VPN while leaving only the embedding endpoint public, reducing the surface reachable by an unauthenticated attacker.
Deploy WAF rules targeting Metabase's query-serving endpoints as a temporary compensating control
The rules above target classic UNION, tautology, and time-based SQL injection payloads against /api/dataset and /api/card. They reduce opportunistic scanning noise but do not close the reset_password injection path itself, since that endpoint's exploit does not rely on the same payload shapes.
Apply the vendor patch for your branch as soon as the maintenance window allows
WAF rules and network restrictions are stopgaps. The only complete fix is the version upgrade identified in the affected versions section above.
Known limitations of this advisory
Every dashboarding tool's real blast radius is defined by what it is connected to, and that is precisely the piece no vulnerability advisory, including this one, can enumerate on your behalf. A CVSS 10.0 unauthenticated admin takeover of Metabase is only as damaging as the credentials Metabase happens to hold for your specific backend databases, and that varies from a read-only reporting user with limited scope to a connection string with full write access to a production database. Treat the severity here as a ceiling, not a fixed number, and confirm what each of your instance's connected data sources actually grants before deciding how urgently to respond.
A second limitation is source corroboration for the exact word-for-word exploitation mechanics: the technical detail cited here (the extra-field pattern reaching an unvalidated user lookup) comes from Bishop Fox's published writeup and the vendor's own security advisory, and while both are credible primary sources for a vendor-disclosed CVE, this advisory has not independently reproduced the exploit against a lab instance. If your environment needs proof beyond vendor and researcher disclosure before prioritizing a patch window, treat that reproduction as a gap to close internally rather than something this advisory can substitute for.
Third, patch version guidance here reflects the fixed builds published at the time of writing (58.24, 59.21, 60.17, 61.11, 62.9, 63.5). Metabase ships frequent point releases, so confirm against the current advisory at GHSA-vwf4-m7j8-wcjf rather than assuming these numbers stay the floor indefinitely.
The bottom line
CVE-2026-72898 is as close to a worst-case scenario as an unauthenticated web application vulnerability gets: no credentials needed, a CVSS 10.0 score, confirmed active exploitation including against Metabase's own Cloud infrastructure, and a blast radius that extends past the vulnerable application into every database it was trusted to query. The fix is a version upgrade, not a configuration tweak, and the WAF and network mitigations above only buy time until that upgrade happens. If Metabase is reachable from the internet in your environment, patching it should move ahead of lower-severity work already on the queue, and the credential rotation step matters even for instances patched today, since exploitation predates public disclosure.
This analysis is generic. create a free account to score threats like this against your own stack.
Frequently asked questions
What is CVE-2026-72898?
CVE-2026-72898 is a CVSS 10.0 unauthenticated SQL injection vulnerability in Metabase, a business intelligence and dashboard tool. An attacker with no account can send a crafted request to the /api/session/reset_password endpoint, inject SQL into Metabase's application database, and take over an administrator session.
Which Metabase versions are affected by CVE-2026-72898?
Both Metabase Open Source and Enterprise Edition are affected in the 0.58/1.58 through 0.63.4/1.63.4 range prior to patching. Fixed releases are 58.24, 59.21, 60.17, 61.11, 62.9, and 63.5, depending on your release branch.
Is CVE-2026-72898 being actively exploited?
Yes. Metabase confirmed exploitation against its own Cloud environment on 2026-08-06, and CISA has added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog with a confirmed exploited status, meaning US federal civilian agencies are on a mandated patching deadline.
How is CVE-2026-72898 actually exploited?
The exploit runs through the /api/session/reset_password endpoint. Password reset requests are supposed to only carry a token and a new password, but Metabase's implementation lets additional, undeclared fields in the request body reach the user-lookup query as structured input, enabling SQL injection without any prior authentication.
How do I detect exploitation attempts against CVE-2026-72898?
Monitor Metabase's own access logs, forwarded to a SIEM, for POST requests to /api/session/reset_password that include more than the two documented fields (token and password). EDR and endpoint agents will not see this activity, since the exploitation happens at the HTTP request and database query layer, not on the host's process tree.
What should I do if my Metabase instance connects to multiple production databases?
Patch first, then rotate every credential Metabase stores for its connected data sources, since an admin-level compromise exposes all of them regardless of which one the attacker actually queried. The real severity of this CVE for your environment depends entirely on what those connected databases can do, which is something only you can assess.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.