Metabase had a CVSS 10.0 zero-day this month. Here's what a small business running dashboards needs to check

A lot of small teams end up running Metabase at some point. It’s free, it’s the fastest way to point a dashboard at a Postgres database (the same database we wrote about recently as our default choice), and it turns “can someone pull a report on this” into a link anyone on the team can open. That convenience is exactly why the vulnerability disclosed in early August 2026 matters: it wasn’t a bug in some obscure module, it was in the front door.

What actually happened

On August 3, 2026, security researchers and Metabase itself confirmed active exploitation of a maximum-severity flaw, tracked as GHSA-vwf4-m7j8-wcjf with a CVSS score of 10.0 out of 10. That top score isn’t hype. The bug lets an attacker with no account, no password, and no prior access send a single request to Metabase’s /api/session/reset_password endpoint and inject arbitrary SQL directly into the application database. From there, they can walk straight to administrator access.

Once an attacker has that admin session, they can read the credentials Metabase stores for every connected database, pull whatever data those connections can see, and export it. For a tool whose entire job is sitting between your team and your production data, that’s about as bad as a vulnerability gets.

Every release from version 58 through 63 was affected, both the open-source and paid editions. Metabase shipped fixes within hours of confirming exploitation: 58.24, 59.21, 60.17, 61.11, 62.9, and 63.5. If you’re on Metabase Cloud, the company patched everything automatically and you didn’t need to do anything. If you’re self-hosting, and a large share of small businesses running Metabase are, the patch only helps once you actually apply it.

Who got caught

Two companies have publicly confirmed they were hit while the flaw was still unpatched. Framework, the laptop maker, disclosed that customer names, addresses, phone numbers, and emails were accessed through its analytics environment. Tally, the online form builder, said its Metabase instance was compromised on August 3 and attackers pulled customer email addresses and password hashes, though it says submitted form responses live in a separate database and weren’t touched. Metabase notified Tally of the breach on August 6 and the affected system was shut down the same day.

Neither of those is a fly-by-night operation. Both run real security teams. The lesson isn’t “these companies were careless.” It’s that an unauthenticated, no-login SQL injection in a tool this widely deployed doesn’t need the victim to make a mistake. It just needs the box to be reachable and unpatched.

What to actually do

If your business or your vendor runs a self-hosted Metabase instance, in order:

1. Check your version and upgrade now. Anything from 58.0 up to 58.23, 59.0 to 59.20, 60.0 to 60.16, 61.0 to 61.10, 62.0 to 62.8, or 63.0 to 63.3 is vulnerable. Upgrade to 58.24, 59.21, 60.17, 61.11, 62.9, or 63.5 depending on which branch you’re on.
2. If you can’t patch immediately, block the endpoint. Put /api/session/reset_password behind a rule that denies external access at the load balancer or reverse proxy until the upgrade goes in. This is a stopgap, not a fix, but it closes the door attackers were actually using.
3. Assume compromise if you were exposed and unpatched between early August and whenever you applied the fix. Delete every row from the core_session table to force everyone, including any attacker, to log back in. Review every API key and admin account for anything you don’t recognize.
4. Rotate the credentials Metabase stores for its connected databases. If an attacker had admin access, they had your stored database credentials too. Patching Metabase doesn’t invalidate keys that already leaked.
5. Check your data warehouse and Metabase activity logs for queries you don’t recognize, especially around account creation, permission changes, or bulk exports.
6. Ask whether Metabase (or whatever BI tool you run) needs to be reachable from the open internet at all. Most teams only need it from inside the office or over a VPN. An internal tool that never needs a public IP can’t be hit by an unauthenticated internet-facing exploit in the first place.

The broader pattern

This is the second time this year we’ve written about an unauthenticated remote exploit hitting a piece of self-hosted internal software (see our notes from SharePoint’s brutal July), and the shape of the problem is the same both times: a tool that’s genuinely useful, that a lot of small teams stand up themselves without a dedicated security function watching it, sitting exposed to the internet because nobody thought about it after the initial setup.

The same question is worth asking one level up, about software you don’t run at all: a few weeks after this, attackers used an authentication bypass in an IT provider’s remote management console to reach the machines inside its clients’ offices. Somebody owns the patching. Make sure you know who.

Self-hosting a BI tool, an internal wiki, a ticketing system, whatever it is, isn’t the wrong call. Plenty of small businesses have real reasons to keep that kind of software on their own infrastructure instead of paying for a hosted version. But self-hosting comes with an ongoing obligation: someone has to own patching it, and someone has to ask, honestly, whether it needs to be internet-facing in the first place. A password-reset endpoint with no authentication check in front of it is exactly the kind of corner that gets cut when nobody owns that question.

If you’re not sure whether the internal tools your team runs are patched, exposed to the public internet when they shouldn’t be, or worth keeping self-hosted at all, send us a note and we’ll help you work through it.