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).

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

Table of contents

• What actually happened
• Why a SQL injection scores CVSS 10.0
• Affected and patched versions
• Immediate measures
• 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.

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:

For the 10.0 flaw the affected range in x.63 ends at x.63.3, for the second at x.63.4 - 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.

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

Neither advisory carries a CVE number. Metabase published them as GitHub Security Advisories; no assignment has been made so far.

That is not unusual, but it has practical consequences: a vulnerability scanner matching against the National Vulnerability Database reports nothing for these flaws - even though one of them is 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
• FIRST: CVSS v3.1 specification document (scope metric)
• BSI: NIS-2 and reporting duties for companies