Zero-Day SQL Injection Active Exploit

Metabase's password reset endpoint handed attackers admin

Aug 10, 2026·10 min read·Chris Boker, Founder, CVEasy AI
A dark envelope shaped as a password reset request sits on the left, its lid open with a rust arrow injecting a green quotation-mark SQL fragment into a central beige cylinder labeled by shape as the Metabase application database, gold key tokens rising out of the cylinder along a mint arc into a right-side rack of surface tiles representing connected Postgres, MySQL, Snowflake, and API data sources, with two smaller rust tiles at the bottom right marked as Framework and Tally to show where the stolen records ended up

On Monday, August 3, 2026, Metabase's own hosted platform started seeing an attack pattern its engineers had not seen before: an unauthenticated POST to /api/session/reset_password that returned 400, followed within seconds by a GET to /api/user/current that returned 200. A failed password reset should not produce an authenticated session. Somebody was using the reset endpoint to run their own SQL against Metabase's metadata store, and by the time the reset bounced they were already an administrator. Metabase patched Cloud, cut a coordinated release across every supported self-hosted branch, and on August 7 and 8 named two breached customers: Framework, the modular laptop maker, and Tally, the accounting and ERP vendor (GHSA-vwf4-m7j8-wcjf, Metabase security update). CVSS 10.0, no CVE number as of this writing.

Where the SQL got in

The reset endpoint accepts {"token": "...", "password": "..."}. The handler looks the token up in the core_user and login_history tables of Metabase's application database, verifies expiry, and if everything checks out writes the new hashed password. The application database is not an analytics warehouse. It is Metabase's own metadata store on H2, Postgres, or MySQL, holding users, sessions, permissions, and the encrypted credentials for every data source the instance has ever queried.

Metabase has not published the exact injection primitive, and I am not going to invent one, but the shape is clear enough from what has been disclosed. The token field reached a query without being fully parameterised, the same class of mistake that put a decade of Rails and Django CVEs on the map. A reset with a fabricated token still returned a legitimate 400 because no such token matched a user, but the side-effect statements the attacker appended, an UPDATE core_user SET is_superuser = true WHERE email = ..., an INSERT INTO core_user ..., or a session row written straight into core_session, had already committed before the outer reset failed. The 200 on the follow-up call to /api/user/current is the injected admin session responding, which is why the request signature Clever Cloud published, POST 400 on reset_password followed by GET 200 on current, catches the mechanism more cleanly than any WAF regex (Clever Cloud changelog, Aug 7 2026).

The endpoint you cannot turn off. You cannot rate-limit or IP-scope your way out of this one at the perimeter. Reset flows have to accept traffic from the whole internet, and the payload is a valid POST body with legitimate JSON. Blocking /api/session/reset_password upstream is the documented interim mitigation, and it breaks self-service resets for real users until the patch lands.

From admin insert to the crown jewels behind the BI tool

Every warehouse connection an operator has ever configured lives in the metadata store as an encrypted credential the application decrypts on demand. The moment an attacker holds admin, that same decryption path is available through legitimate admin APIs. They can list every data source, run arbitrary SQL against Snowflake, BigQuery, Postgres, MySQL, Redshift, or whatever else is wired in, and export result sets through the same download endpoints an analyst uses. There is no second bug to chain. The Metabase admin surface is by design a query-anything cockpit; the vulnerability turned it into an exfiltration console for anyone who could reach the reset endpoint. Affected branches are 0.58.0 through 0.58.23, 0.59.0 through 0.59.20, 0.60.0 through 0.60.16, 0.61.0 through 0.61.10, 0.62.0 through 0.62.8, and 0.63.0 through 0.63.4, with the enterprise 1.x tags of those branches vulnerable on identical code paths. Fixed releases are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 (GHSA-vwf4-m7j8-wcjf).

What Framework and Tally lost

Framework's and Tally's notices, summarised by BleepingComputer on August 7 and echoed by The Hacker News, describe theft of customer records containing names, email addresses, phone numbers, shipping addresses, and company details. Neither reported password hash theft, which fits the model: the attacker pulled rows out of an analytics warehouse through legitimate queries rather than dumping an auth table. You lose whatever your analysts can see, and analysts see quite a lot on purpose. No vendor attribution has landed; the pattern reads like commodity scanning against the endpoint fingerprint with targeted follow-on against instances that returned the expected error shape.

Why a CVSS-first queue mis-ranks this

The severity of 10.0 is honest, so the risk with a CVSS-first queue is not undercounting. It is the opposite: every Metabase in your inventory gets the same maximum score even though the exposure varies wildly between instances. A production Metabase reachable from the internet with a live Snowflake service account is not on the same rung as a sandbox an analyst spun up for a demo, and CVSS 10 sorts them side by side and asks you to patch both by the same deadline. That is not a knock on CVSS; it is a knock on treating the base score as the queue instead of the input to the queue.

TRIS on this event: the four layers that decide the rank

TRIS is the Threat and Risk Intelligence Scoring engine inside CVEasy AI. It scores an event against your inventory so the same GHSA lands in different bands on different boxes.

Exploitation status. Confirmed in the wild. Metabase Cloud caught live abuse on August 3, Framework and Tally have both published notices, and Clever Cloud captured a repeatable request signature in production traffic. Top band. A proof of concept alone would not have got there; confirmed customer breaches did.

Exposure surface. A Metabase reachable from the public internet with no upstream rule hiding the endpoint sits at ACT. An instance behind an authenticated reverse proxy that terminates unauthenticated traffic before it hits /api/session/reset_password, or one bound to a private network only, drops several bands.

Downstream blast radius. The layer that separates a BI tool from a plain web app. TRIS walks the connections attached to each Metabase instance and weighs them by what they read. A Metabase with production Postgres, a Snowflake role scoped to sensitive customer schemas, and a Salesforce API connection carries heavier blast radius than one wired to a single BigQuery view. Same CVSS 10, different queue position.

Recovery cost. If the instance was reachable and vulnerable during the exploitation window, the response is not simply patching the binary. Every credential in metabase_database has to be treated as leaked. The gap between a five-minute upgrade and a two-day credential rotation is the actual work your team is committing to.

Patch, block, rotate, hunt

Rotate first, then investigate. If an instance was reachable during the Aug 3 window on a vulnerable version, every warehouse credential and every SaaS token in that instance's data sources is compromised, regardless of what your egress logs show. Rotate before you audit. The exfiltration path is a legitimate query API and will not look anomalous.

1. Upgrade. Move to 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5 on your branch, or the matching enterprise 1.x tag. Straight version bump.

2. If you cannot upgrade in the same window, block the endpoint upstream. Reject POST to /api/session/reset_password at the reverse proxy or WAF. Self-service resets stop until it is unblocked; helpdesk resets go through internal user administration in the meantime.

3. Hunt the request signature. In the last 45 days of web-server logs, POST /api/session/reset_password returning 400 followed within 5 seconds by GET /api/user/current returning 200 from the same source is the smoking gun; any hit means confirmed compromise on that instance.

4. Rotate every credential in every affected instance's data sources. Warehouse service accounts (Snowflake, BigQuery, Redshift, Databricks), database roles (Postgres, MySQL, SQL Server), SaaS API tokens, and any secrets in Metabase's own settings. The admin API reads them all through legitimate calls once an attacker is in.

5. Audit admin actions in the exploitation window. Bulk exports, new admin users you did not provision, and elevation of an existing account to superuser are the first entries to pull from Metabase's audit log.

How CVEasy AI surfaces this when the crown jewels sit behind a BI tool

CVEasy AI is the number one local-first CTEM platform, and this event is the shape it is built to answer on your own hardware. It ingests advisories and disclosure notices from the sources cited above alongside NVD, matches affected Metabase versions to your own inventory, and runs the finding through TRIS against your network posture and data-source graph. Output is a short list: which instances are on a vulnerable branch, which are reachable from the public internet, which warehouses and SaaS tokens each one holds, and which show the POST 400 then GET 200 signature in the last 45 days. Your inventory, connection graph, and request logs never leave your infrastructure, which is precisely the point when the finding is that another vendor's SaaS just read your customer table through a legitimate query.

Sources: Metabase security advisory GHSA-vwf4-m7j8-wcjf, Metabase security update, BleepingComputer, The Hacker News, Cyber Security News, Clever Cloud changelog, SecurityIntel digest, 8 Aug 2026