Metabase emergency patch: SQL injection rated CVSS 10.0 is being actively exploited

Want self-hosted software watched before it burns? We monitor vulnerabilities for the systems we operate and patch within the agreed window - see CVE monitoring and managed operations, or book an initial consultation.

Metabase closed two critical vulnerabilities on 6 August 2026. The more severe one carries CVSS 10.0 and is, according to the vendor, being actively exploited: an unauthenticated attacker can inject SQL into the application database through the /api/session/reset_password endpoint and gain administrator rights (GHSA-vwf4-m7j8-wcjf).

The flaw was exploited as a zero-day, before a patch existed. Confirmed consequences have since surfaced: laptop maker Framework and form provider Tally have both disclosed data theft.

Two things make this case interesting beyond Metabase itself. First: it is "only" a SQL injection and still scores the maximum. Second: at publication there was no CVE number, it followed four days later - anyone whose vulnerability management rests on CVE feeds alone is not seeing this flaw right now.

Updated on 9 August 2026 with the confirmed data theft, the detection pattern from the access logs, and the now-clarified status of Metabase Cloud.

Table of contents

• What actually happened
• What was actually stolen
• Why a SQL injection scores CVSS 10.0
• Affected and patched versions
• Immediate measures
• Spotting a compromise
• Follow-up work after the update
• A flaw without a CVE - the blind spot in monitoring
• What this means for analytics tools in general
• How we approach it at WZ-IT
• Further guides

What actually happened

Metabase published two advisories on 6 August 2026. Both are SQL injection into Metabase's application database, both lead to administrator access - they differ in what the attacker needs.

The difference in the vector is exactly one letter: UI:N against UI:R. The first flaw requires no interaction at all - no click, no login, no precondition. For the second, the UUID of a public link is enough; public sharing is enabled by default in Metabase.

An important clarification: this is not remote code execution. No code runs on the server. That does not make it milder, as the next section shows - but anyone hunting for RCE signatures is looking for the wrong pattern.

What was actually stolen

The attack took place on 3 August 2026, three days before the patch. Metabase notified affected customers on 6 August; the cases became public on 7 August.

A distinction that gets lost in much of the reporting: the confirmed incidents involve Metabase Cloud. Framework ran a Cloud instance, and Metabase detected the attack on its own platform. Self-managed instances are vulnerable, but an attack on a specific self-hosted installation has not been publicly documented so far.

For self-hosting operators that changes nothing about the urgency, quite the opposite: the vendor states it has already upgraded Cloud instances. Anyone running their own has to act themselves - and without log analysis will not know whether they were hit.

Why a SQL injection scores CVSS 10.0

The decisive part of the vector is S:C - scope changed. It states that the damage crosses the boundary of the vulnerable component.

That is exactly the situation with a business intelligence tool. Metabase is not a system that holds its own data. It is a system that holds credentials to other people's data: PostgreSQL, MySQL, Snowflake, BigQuery, Redshift, the data warehouse. Whoever becomes a Metabase administrator then reads out the stored connections.

The arithmetic is therefore not "one compromised analytics tool" but "compromised access to every connected data source". In its impact assessment the vendor explicitly names the theft of stored database credentials and data exfiltration through the connected systems.

That is why a flaw without code execution lands at the maximum score - and why the update alone is not enough.

Affected and patched versions

Metabase maintains several branches in parallel. Affected are:

The table shows the wider of the two ranges, i.e. the question "am I affected by either flaw?". The actively exploited 10.0 flaw reaches one point release less far: GitHub lists it as >= x.58.0, < x.58.23 through >= x.63.0, < x.63.3, so the affected builds there end at x.58.22 and x.63.2 respectively. Anyone on x.63.3 or x.63.4 is no longer affected by the 10.0 flaw, but very much by the second one - in both cases x.63.5 resolves it. Anyone running a major version older than x.58 has to move to one of the maintained branches before the patch applies.

You can check the running version in the Metabase admin settings or directly from the container tag.

Immediate measures

Updating remains the first choice. Where that cannot happen within hours, the vendor names stopgaps:

• For the unauthenticated flaw: block the /api/session/reset_password endpoint at the network level - in the reverse proxy, the web application firewall or the ingress rule. This disables password resets, which is no loss at all in environments with SSO.
• For the second flaw: disable public sharing, or at minimum unpublish every public link that carries field-filter parameters.

Both are makeshift. They close a known path, not the vulnerability.

The most effective protection is structural anyway: an analytics tool has no business being on the open internet. Reachability exclusively through identity-based remote access instead of a public port would have left both attack paths with nothing to work on.

Spotting a compromise

Metabase names a concrete pattern to search for in access logs:

POST /api/session/reset_password   → 400
GET  /api/user/current             → 200

A call to the password reset endpoint that appears to end in an error, immediately followed by a successful request for the current user. The first call only fails outwardly; the injection has already taken effect by then, and the second call reveals the valid session.

This is a solid starting point because it can be found in any reverse proxy or ingress log, without Metabase itself having to record anything. The relevant window starts on 3 August 2026 at the latest.

If your logs do not reach back that far, you cannot answer the question and should work through the follow-up section below in full rather than hoping for a negative finding.

Follow-up work after the update

For the actively exploited flaw, applying the patch is explicitly not sufficient. Anyone who ran a reachable instance has to assume access may have taken place. The vendor names five steps:

1. Delete all sessions - remove the entries in the core_session table so that hijacked sessions become invalid
2. Review API keys and revoke everything you cannot account for
3. Go through the admin accounts - newly created accounts and changed roles are the first sign
4. Rotate database credentials - every one stored in Metabase
5. Evaluate the access logs of the connected systems and review the activity history inside Metabase

Point 4 is the most laborious and the most important. If the stored credentials have leaked, a patched Metabase helps nothing - the attacker then talks to the database directly.

Point 5 is where most fail. Anyone who keeps no logs, or cannot evaluate them, cannot answer the question "did something happen?" - and has to assume the worse case.

A flaw without a CVE - the blind spot in monitoring

Update of 31 August 2026: The more severe of the two flaws now has an identifier. It is tracked as CVE-2026-72898, confirmed at CVSS 10.0, and CISA added it to the Known Exploited Vulnerabilities catalog on 11 August 2026 with a remediation due date of 14 August. The section below describes the situation at the time of the attack; the monitoring gap has not disappeared but has become measurable for the first time.

Four days therefore passed between the advisory and the CVE number. Anyone whose vulnerability management rests on CVE feeds alone had no indication during that window of a flaw that was already being exploited.

At the time this article was published, neither advisory carried a CVE number. Metabase had published them as GitHub Security Advisories; no assignment had been made.

That is not unusual, but it had practical consequences: a vulnerability scanner matching against the National Vulnerability Database reported nothing for these flaws - even though one of them was being actively exploited. Anyone whose vulnerability management rests on CVE feeds alone has a blind spot here that may last several days.

Reliable monitoring for self-hosted software therefore pulls several sources together: CVE and NVD, but also the GitHub Security Advisories of the projects in use, their release notes and vendor announcements. How we set that up is described in CVE monitoring for self-hosted software.

What this means for analytics tools in general

The Metabase case is not an isolated incident but a pattern. Business intelligence tools, ETL pipelines and dashboard platforms all share one property: they are credential vaults. Their whole job is to connect to as many data sources as possible.

Three rules follow from that, independent of the product:

Not publicly reachable. A BI tool has no reason to be reachable from the open internet. Access through identity-based remote access with multi-factor authentication costs little and removes the basis for an entire class of attacks.

Separate database users with read-only rights. If Metabase connects with an account that may only read and only sees the schemas it needs, a compromised Metabase is a data leak - but not a takeover of the data warehouse.

Keep credentials rotatable. Follow-up step five above only takes hours instead of days if somebody wrote down beforehand which credentials are stored where.

How we approach it at WZ-IT

For the systems we operate we monitor vulnerabilities not only through CVE feeds but through the advisory channels of the projects in use - precisely because cases like this one arrive without a CVE number. We assess critical reports against the actual estate: which version runs where, is the instance reachable at all, and does one of the stopgaps apply.

When setting up self-hosted applications we treat the three points from the previous section as standard: no public access, separate database users with least privilege, documented credentials. That is not extra operational effort; it is the difference between a patching weekend and a NIS2 report.

If you are unsure how your existing instance stands: the server audit reviews reachability, access, patch level and restorability on one Linux instance at a fixed price. For ongoing operations, CVE monitoring is the matching building block.

Further guides

• CVE monitoring for self-hosted software - how vulnerability management works without your own security team
• cPanel CVE-2026-41940 - same mechanism, different product
• OPNsense 26.1.8 - patch management at the perimeter
• Linux kernel vulnerabilities 2026 - why patch management belongs on the board agenda
• Managed open source - operating open-source applications with a maintenance window
• Compliance and NIS2 - reporting duties and what they presuppose

Running Metabase and unsure whether the instance is clean? We check version, reachability and traces of access, apply the patch and work through the follow-up - let's talk or go straight to the server audit.

Sources

• GHSA-vwf4-m7j8-wcjf: SQL injection using an unauthenticated endpoint leading to admin access
• GHSA-r8h2-qpfx-mx59: SQL injection using a publicly shared dashboard leading to admin access
• Metabase: overview of all security advisories
• Metabase: Security update available - Please upgrade now
• heise online: Metabase zero-day - data leak at laptop manufacturer Framework
• BleepingComputer: Metabase SQLi zero-day exploited in customer data-theft attacks
• FIRST: CVSS v3.1 specification document (scope metric)
• BSI: NIS-2 and reporting duties for companies