Cyber News / Article / Inside the Metabase SQLi: Exploited in the Wild

Inside the Metabase SQLi: Exploited in the Wild
Reverse engineering Metabase CVE-2026-72898 with AI to accelerate defense.
On August 6th, 2026, Metabasedisclosed a security incident. An attacker used a zero-day SQL Injection vulnerability (GHSA-vwf4-m7j8-wcjf)/CVE-2026-72898) in the Metabase platform against Metabase Cloud.Since then, further announcements have been made by impacted companies, including:
August 7th:Framework
August 7th:Tally
August 8th:n8n
August 9th:Kilo Code (Anaconda)
August 10th:ChecklyHQ
Self-hosted Metabase instancesmust be patched as soon as possible. Wiz Researchpublished a Threat Intel Center alert to customersupon Metabase’s disclosure. However, given the severity of this vulnerability and reported in-the-wild exploitation, we think it’s important to share more publicly. We also wanted to use this as an opportunity tohighlight how AI can accelerate defensive security.
As of noon UTC on August 10th, we have observed public proof-of-concept exploits open-sourced.
Wiz observed thatroughly 13% of cloud environments have self-hosted Metabase instancesdeployed. Of those instances, approximately 25% are fully internet accessible.
In terms of public data, we can see ~2,500 Metabase instances inventoried by Shodan.
The initial Metabase disclosure gives a few critical hints as to the underlying vulnerability:
The class of vulnerability is SQL Injection
The entrypoint is/api/session/reset_password
The vulnerability is present in versions 1.58+
Docker images are available for fixed versions
However, the details of the vulnerability were not released, and the patch was only made available via releases - it is not public in the current GitHub repository.
In such cases it is necessary for Wiz Research toreverse engineer the vulnerability, in order to ensure prompt detection and validation can be offered to customers. To do so, we are able to leverage the expertise developed from buildingautonomous AI systems for vulnerability research. We are withholding our full PoC to avoid enabling exploitation, while ensuring defenders have the necessary information to respond.
The process for reversing such vulnerabilities can be generically described through the following process:
Download vulnerable and patched JARs - in this case we usedv0.58.22andv0.58.24
Compare contents and develop a diff
Decompile compiled Clojure for the relevant class
Clone open source code, and correlate bytecode diff to source
Having reversed the patch, use it as a pointer to reconstruct the vulnerability
We prompted an agent with this process, which revealed the SQL Injection vulnerability, with the following (pseudocode) patch as the smoking gun:
The patch validates user-id as a positive integer before querying. However,user-idis not a documented parameter of/api/session/reset_password, which only expects atokenand apassword.
So, we can infer that the vulnerability entails providing an extra user-id key in the JSON body that the API doesn't strip. Following this lead, we used an agent to reconstruct the vulnerability, which ties together a few interesting language and framework behaviors:
Clojure's merge function combines two maps, with the second map's values overwriting the first's. Critically, it does not strip extra keys from the first map, but rather they simply pass through. In the vulnerable code, the incoming request is merged with the authentication result:(merge request (authenticate ...)). When authentication fails, the result contains nouser-id, so an attacker-supplieduser-idfrom the request survives the merge untouched.
JSON keywordization converts JSON keys into Clojure keywords during parsing. An attacker's payload{"user-id": {"raw": "SQL"}}becomes the Clojure map{:user-id {:raw "SQL"}}. This is standard behavior, but it enables the next step.
HoneySQL's:rawkeyword is a feature that allows embedding literal SQL strings, bypassing parameterization. It's intended for cases where developers need to include SQL that can't be expressed through the query builder. When the attacker-controlled{:raw "SQL"}value reaches a HoneySQL query, it's interpreted as a directive to inject the SQL string directly.
The injection completes when the surviving user-id value is passed tot2/select-one :id user-id. Instead of receiving an integer like123, the query receives{:raw "(...)"}, which HoneySQL compiles into unparameterized SQL achieving arbitrary blind SQL injection.
Metabase supportsmultiple databases: H2 by default, but PostgreSQL, MySQL, or MariaDB are recommended for production. The injection payload is database-dependent. The vulnerability has been present since version 1.58. This was whenthe auth_identity module was refactored, which introduced this vulnerability.
Variant Hunting
Once we identified the root cause, we also made a quick pass at identifying any unpatched variants of this issue lingering in the repository. This included generating Static Analysis rules for the relevant code patterns, running them to generate candidates, and using our agentic approach to validate or invalidate those candidates. In this case, we reviewed all merge.*request patterns, as well as all auth-identity/login! call sites.
If you need to investigate manually:
Review/api/session/propertiesto determine if a Metabase instance is running a vulnerable version
To check for exploitability, you should modify the following command with your desired SQL:
Refer to the Metabase blog forImmediate steps to takeif you are exposed.
Wiz customers should refer tothe pre-built advisoryin the Wiz Threat Intel Center for actionable steps to investigate, remediate, and harden their environments. Wiz Research will continue to update that advisory as the situation develops.
Github Security Advisory
Metabase Security Update
Cloud and AI threat activity tracked by Wiz Research and CIRT, January through June 2026
Automating DISA STIG Compliance for Amazon Linux 2023 and Windows Server 2025, giving defense and federal teams immediate and continuous hardening validation.
Announcing new capabilities that help organizations prepare for the AI era by expanding visibility and accelerating response, so security teams can defend at machine speed.
Get a personalized demo
©2026Wiz, Inc.
StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings
Related articles
Chrome V8 Zero-Day Exploited in the Wild Enables Code Execution Inside Sandbox
2 days ago
Microsoft Patches Record 974 Flaws, Including Two Exploited Windows Zero-Days
2 days ago
N-able N-central Pre-Auth RCE Flaw Exploited in the Wild
2 days ago

