Metabase Shipped a CVSS 10.0 With No CVE. Your Scanner Cannot See It, KEV Cannot List It, and 19,810 Instances Are Waiting on a Human to Notice.

Metabase disclosed on 7 August that a maximum-severity flaw in its business intelligence platform had already been exploited as a zero-day. An unauthenticated attacker can inject arbitrary SQL into the application's own database and come out the other side as an administrator of the instance.

Two things about it are worth more attention than the flaw itself.

The first is that it has no CVE identifier. A CVSS 10.0, actively exploited, with nothing for a scanner to match on.

The second is that Metabase Cloud was patched centrally and self-hosted was not. If you run this yourself, the vendor did not fix it for you. A person has to read an advisory and act.

We counted the exposure, because nobody else was going to

Shodan returns 19,810 internet-facing Metabase instances on a title match, and 12,823 on a product fingerprint, queried 8 August.

5,246 of them answer on port 3000 — the default, published straight to the internet with no reverse proxy in front of it.

By hosting provider: Amazon across four AWS organisation strings totals 6,341, DigitalOcean 1,881, Google 1,148, Hetzner 952, A100 ROW 544. By country: United States 7,580, Germany 2,168, India 1,072, Ireland 813, France 811, Singapore 795, United Kingdom 759.

That provider breakdown is the point, and it is easy to misread. Running Metabase on AWS does not make it Metabase Cloud. Those are self-managed deployments that happen to sit on rented infrastructure. The tenant patches, not the vendor. A great many people have quietly assumed that "it's in the cloud" and "somebody else patches it" are the same sentence. They have never been the same sentence.

One honest limit, stated up front: Shodan does not report a Metabase version in its fingerprint. So we can tell you how many instances are reachable. We cannot tell you how many are unpatched, and we are not going to estimate it. A count of exposed instances is not a count of vulnerable instances, and anybody presenting it as one is selling you something.

The part that should bother your vulnerability management programme

There is no CVE.

Metabase rated this 10.0 and shipped fixes, but without a CVE identifier the flaw does not exist in the plumbing most organisations actually rely on. Your scanner matches on CVE. Your SBOM tooling matches on CVE. Your patch SLA is written in terms of CVE severity. CISA's Known Exploited Vulnerabilities catalogue requires a CVE, so an actively exploited 10.0 cannot be listed there at all.

This is a beat we have been on for a while: the vulnerabilities that hurt people are disproportionately the ones nobody labelled. A silently patched remote code execution with no security advisory. A dependency bump in a changelog. And now a maximum-severity authentication bypass under active exploitation with no identifier for a machine to key on.

The label failure is the story. If your entire detection of "am I affected" runs through a CVE feed, then for this flaw your programme is blind by design, and it will be blind again next time.

Four days

Attackers reached the Metabase instances of Framework and Tally on 3 August. Metabase notified Framework on 6 August. Public disclosure came on 7 August.

Framework, the modular laptop maker, told customers that names, email addresses, login IP addresses, billing and shipping addresses, phone numbers and company names were accessed, along with VAT and EIN details for business accounts. Payment information was not affected.

Tally reported email addresses and password hashes taken, and — creditably — said it could not confirm at time of reporting whether those hashes were salted. That is an uncomfortable sentence to publish and it is the right one to publish.

Cloud tenants were already upgraded when the announcement landed. Self-hosted operators started their clock four days after the attacks began.

Why administrator on a BI tool is worse than administrator on a server

This is the part that generalises past Metabase, so it is worth sitting with.

A business intelligence platform is a credential vault with a chart library bolted on. It cannot draw a single graph unless it holds working credentials for every database it reports against, and it has to hold them in a form it can use unattended, because the whole point is scheduled reports that run at 6am without a human present.

So administrator on the instance is not administrator on one application. It is the saved connection credentials for the production database, the warehouse, the analytics replica that is usually a full copy and usually less monitored, and whatever the finance dashboard reads.

And the downstream systems never see an intrusion. They see their normal reporting user asking normal questions, from the normal address, with the normal credentials. Exporting to CSV is a product feature, not an exploit. Every control you have downstream is looking for something that does not happen.

What to do, in order

If you cannot patch within the hour, block the password reset endpoint at your proxy. The injection lands through a POST to the session reset path. Block it and the chain never starts. You lose self-service password reset until you patch, which is a fair trade for an afternoon.

Then upgrade. The fixed releases are 1.58.24, 1.59.21, 1.60.17, 1.61.11, 1.62.9 and 1.63.5. Affected ranges are 1.58.0 through 1.58.23, 1.59.0 through 1.59.20, 1.60.0 through 1.60.16, 1.61.0 through 1.61.10, 1.62.0 through 1.62.8, and 1.63.0 through 1.63.4.

Then check whether it already happened, because you can. Metabase's own detection guidance is two lines in an access log you already have: a POST to the session password reset endpoint returning 400, immediately followed by a GET to the current user endpoint returning 200. A failed reset followed by a successful authenticated identity call. Per Metabase's CEO, that sequence means the instance is likely compromised.

We want to be clear about how good that is. It is behavioural. It needs no IP list, no file hash, no threat feed and no subscription to anything. A defender with nothing but grep and their own logs can answer this question today. That is a rarer gift than it should be.

If you find it, assume the credentials are gone. Revoke every session, review API keys, audit administrator accounts, rotate the database credentials Metabase had stored, and read your data warehouse logs. The point of administrator on a BI tool is everything the BI tool can reach, so the incident scope is your data estate, not your Metabase box.

The fix that outlives this patch

Step four in that flow — reading the stored connection credentials — has nothing to do with this vulnerability. Any authentication bypass in any BI platform ends the same way, because storing live credentials is what the category does.

Which means the durable mitigation is not patching. It is giving the BI tool a read-only account, scoped to the views it actually reports on, pointed at a replica rather than production. Do that and administrator on Metabase is worth exactly what Metabase can see, instead of everything Metabase can reach.

That is more work than applying an update, and it is the only version of this that still helps you next time.

Nothing to add to the feed, and we will say so

There are no network indicators to publish here. No attacker infrastructure has been released, no hashes, no domains. There is no CVE for us to correlate against our KEV mirror either.

So there is nothing to ingest, and we would rather tell you that than manufacture a receipt. The useful artefact for this one is the two-line log signature above, which belongs in your SIEM and not in anybody's indicator feed.

For the record, we have carried a Metabase entry in our KEV mirror before: CVE-2021-41277, the GeoJSON local file inclusion flaw. This platform has been on the exploited list previously, which is worth knowing if you are deciding how much attention it deserves in your environment.

The accounting

Metabase found and disclosed this and shipped the fixes. Framework and Tally disclosed their breaches quickly and with real detail, which is the behaviour that lets everyone else defend themselves. The Hacker News and BleepingComputer did the reporting. We did none of that.

Our contribution is the exposure measurement — 19,810 reachable instances, where they are hosted, and the fact that 5,246 of them are sitting on the default port — plus the argument that the cloud-versus-self-hosted split is the whole story, and the note that a CVSS 10.0 without a CVE is invisible to the tooling most defenders actually run.

We guarantee five percent of what we publish is wrong. The most likely five percent here is the exposure count: Shodan sees what Shodan sees, banner fingerprints drift, and some fraction of those 19,810 are honeypots, staging boxes and duplicates. What we are confident about is the direction — this is tens of thousands of instances where a human being has to notice, and the four-day head start belonged to somebody else.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.