Article

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

    Inside the Metabase SQLi: Exploited in the Wild
    Ra
    Rami McCarthy-2026-08-10

    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

    Original source