Inside the Metabase SQLi: Exploited in the Wild

What to do

The summary names the curl-based check but not the command. To test exploitability, modify the payload with your own SQL:

curl -X POST https://TARGET/api/session/reset_password \
-H "Content-Type: application/json" \
-d '{"token":"x","password":"y","user-id":{"raw":"SQL_PLACEHOLDER"}}'

To fingerprint the version (and thus whether an instance is vulnerable) without exploiting, review the /api/session/properties endpoint. Self-hosted instances must be patched immediately; the fix ships only in releases, not in the public GitHub repo.

Preconditions / Affected

Vulnerable from version 1.58 onward — introduced when the auth_identity module was refactored. Wiz used v0.58.22 (vulnerable) and v0.58.24 (patched) to build the diff. The injection is blind and its payload is database-dependent: H2 by default, but PostgreSQL/MySQL/MariaDB in production, so a working payload must match the backend.

How the fix works (the smoking gun)

The patch validates user-id as a positive integer before it reaches the query:

(if (pos-int? user-id)
  (t2/select-one [:model/User ...] :id user-id)
  (log/warnf "... refusing to resolve a user." ...))

Because /api/session/reset_password documents only token and password, the presence of a user-id guard confirms the attack shape: an undocumented user-id key that isn't stripped, surviving the (merge request (authenticate ...)) when auth fails, then reaching HoneySQL as {:raw "SQL"}.

Exposure and exploitation status

Beyond the ~2,500 Shodan-inventoried instances the summary cites, Wiz observed that ~13% of cloud environments run self-hosted Metabase, ~25% of those fully internet-accessible. As of noon UTC August 10th, 2026, public proof-of-concept exploits have been open-sourced — so the exploitability window for unpatched instances is now wide, not theoretical. Wiz is withholding its own full PoC.

Note on methodology

The post also describes variant hunting after root-cause: generating static-analysis rules for the relevant patterns, then using an agent to validate candidates. They reviewed all merge.*request patterns and every auth-identity/login! call site — a repeatable approach if you maintain a Clojure/HoneySQL codebase and want to check for the same class of bug.