Metabase Cloud Customers Were Patched Before They Knew. Self-Hosted Users Had to Do It Themselves.

On August 6 the analytics vendor Metabase said its own cloud service had been attacked through a flaw nobody knew existed. The flaw, now tracked as CVE-2026-72898, scores a perfect 10 on both current CVSS scales. It lets an attacker with no account inject SQL through a public password-reset endpoint and end up as administrator of the instance.

What happened next is the part worth reading. Cloud customers were upgraded before most of them heard about it. Everyone running Metabase on their own server had to learn about the attack, find their version, patch it and then go looking for evidence of a break-in. Within four days five customers had come forward, two of them detailing stolen data, proof-of-concept exploit code was public, and CISA had put the flaw on its list of vulnerabilities under active attack.

Key facts

• What it is. CVE-2026-72898, an unauthenticated SQL injection in /api/session/reset_password. CVSS 10.0 on both v3.1 and v4.0.
• What an attacker gets. Administrator access, and from there the power to change configuration, steal stored credentials for every connected database, read whatever those connections reach, and export it.
• Who is affected. Metabase 1.58 and above. Anything below version 58 is not vulnerable.
• The patched releases. 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5, whichever line you run.
• The split that matters. Metabase Cloud instances were upgraded by the vendor. Self-hosted instances stay vulnerable until someone updates them by hand.
• How exposed the estate is. Wiz found self-hosted Metabase in about 13% of cloud environments, roughly a quarter of those reachable from the internet, and about 2,500 instances visible in Shodan.
• The deadline. CISA added it on August 11 with a due date of August 14, three days, binding on US federal agencies.

One Unchecked Field in a Password Reset

Metabase did not publish the technical detail, and the patch was not visible in the public repository. Wiz reconstructed it by comparing the vulnerable and fixed builds and decompiling the result.

The endpoint expects two things, a token and a new password. It did not object to a third. An attacker could add a user-id field to the request, and because the code merges the incoming request with the authentication result, and a failed authentication returns nothing to overwrite it with, that attacker-supplied field survived intact. It then reached the query builder, where a directive meant for trusted literal SQL let the value through unparameterized. The fix is one check: treat user-id as a positive integer or refuse it.

The result is a blind SQL injection against the application database, which is where Metabase keeps the credentials for every data source it connects to. That is why the vendor’s list of consequences ends with exporting data: the tool is designed to reach warehouses, so an administrator of the tool reaches them too.

Five Disclosures in Four Days

The affected companies made themselves known quickly, which is unusual and useful, because it turns an advisory into evidence.

By noon UTC on August 10, Wiz was seeing public proof-of-concept exploits. A day later the flaw was on CISA’s Known Exploited Vulnerabilities list with a remediation deadline of August 14, three days for the federal agencies it binds and a tight window for anyone.

The Same Software, Two Very Different Weeks

This is the part for anyone who runs software for other people. Metabase Cloud was not spared. It was the thing that got attacked. But the vendor could block the endpoint, patch the code and push it to every hosted instance, so its customers woke up already fixed.

Self-hosting inverts that. Nobody blocks the endpoint for you and nobody upgrades your container. You have to notice the advisory, match your point release against a list of six, apply it, and then assume you may already have been visited. Wiz’s numbers say how large that population is. Metabase turns up in roughly one in eight cloud environments, a quarter of those instances answer to the open internet, and about 2,500 sit in Shodan for anyone to enumerate.

None of this is an argument against self-hosting. It is an argument about who is on the hook. That lands on providers hosting analytics stacks for clients, on agencies that stood up a Metabase for a customer two years ago, and on anyone whose managed-services contract quietly implies that patching is somebody’s job.

Patch, Then Assume You Were Hit

Upgrade to the minimum safe release for your line: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 or 0.63.5. If you cannot upgrade immediately, block access to /api/session/reset_password until you can.

Then look for the break-in, because the vendor published a signature. A POST to /api/session/reset_password returning 400, followed by a successful GET to /api/user/current, in either your application logs or your ingress logs, means the instance was probably compromised.

If the endpoint was ever publicly reachable, Metabase’s own instructions go further than patching:

• Revoke every session by clearing the core_session table in the application database
• Review API keys and delete anything unrecognized
• Check administrator accounts for changes you did not make
• Rotate the credentials of every connected database, because those were sitting in the database the attacker could read
• Review warehouse logs and Metabase’s own query history for access that should not be there

About the Data

Version numbers, remediation steps and the attack signature come from Metabase’s own security post of August 6, 2026. The vulnerability chain and the exposure estimates come from Wiz’s analysis of August 10. Severity and identifier come from the CVE record, and the listing date and deadline from CISA’s Known Exploited Vulnerabilities catalog, version 2026.08.11. We have used the sequence of company disclosures as reported by Wiz; individual companies dated some of their own statements differently.