Published on 13 August 2026
An attacker needs no username, no password and no stolen credentials – a single crafted call to the password reset function is enough to take full administrative control of a Metabase instance. That is exactly what happened with CVE-2026-72898: a critical vulnerability in the popular analytics and dashboard tool Metabase was already being exploited as a so-called zero-day – meaning a flaw that attackers used before a patch even existed. The vendor confirms active attacks, the US agency CISA added the vulnerability to its catalogue of actively exploited flaws on 11 August 2026, and Germany's BSI rates the bug with the highest possible CVSS score of 10.0.
If you or a service provider operate a self-hosted Metabase instance, this article is of immediate, actionable relevance to you. We explain what happened, how to check whether you are affected, and what specific steps you need to take now.
Metabase is a widely used tool that companies employ to analyse their business data and present it in clear dashboards – for example shop revenue, customer data from the CRM, or support tickets. To do this, Metabase connects to the underlying databases and stores their credentials for the purpose.
And this is precisely where the danger lies. On 6 August 2026, vendor Metabase published a security advisory explaining that its own cloud platform had been attacked via a previously unknown vulnerability. The official warning states:
„We recently identified that Metabase Cloud was attacked by someone utilizing an unknown (‚0-day‘) security vulnerability in versions 1.58 and above. We immediately blocked the endpoints used for the attack, then quickly identified and patched the vulnerability.“ (Metabase, security advisory of 6 August 2026)
In plain terms: Metabase Cloud was attacked via an unknown zero-day. The vendor immediately blocked the abused access points, identified the vulnerability and closed it. Metabase Cloud has already been updated – customers here need do nothing further. The actual problem now concerns all self-hosted instances that companies run on their own servers, in Docker containers or at a hosting provider. These must be checked and patched individually.
The vulnerability is a so-called SQL injection (technical classification CWE-89). This means: an attacker injects their own database commands into a query that was actually only supposed to process harmless values. The database then executes these smuggled-in commands as if they came from the application itself.
The attack path is the /api/session/reset_password endpoint – the function you normally use to reset a forgotten password. According to the technical reconstruction by security firm Wiz, in a faulty flow an additional value that was sent along („user-id“) was retained and interpreted by the SQL library in use as a raw database command. This very value was able to reach a query against the Metabase application database. The patch fixes this by only accepting positive integers as the user ID for this query.
What is decisive – and what makes this vulnerability so dangerous – is the combination: the attack is possible over the network, requires no authentication and no user interaction. The vendor's GitHub security advisory sums up the consequences as follows:
„This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance.“ (Metabase, GHSA-vwf4-m7j8-wcjf)
According to the vendor, a successful attacker can:
An important point for context: this is not a vulnerability in the connected databases themselves. But because Metabase stores their credentials and offers export functions, a pure reporting system can become a gateway to customer- and business-critical data – depending on which permissions the stored database connections hold.
According to observations by Wiz, public attack tools were freely available by around midday (UTC) on 10 August 2026 at the latest:
„As of noon UTC on August 10th, we have observed public proof-of-concept exploits open-sourced.“ (Rami McCarthy, Wiz Research)
For protective reasons, this article contains no exploit details or reproducible attack steps.
Affected are self-hosted Metabase instances from version 1.58 (or 0.58) onwards that have not yet been updated to one of the corrected versions. Versions below 0.58 are not affected, according to the vendor. Metabase Cloud has already been updated by the provider.
For small and medium-sized enterprises, this means: it is not the normal visit to your website that is at risk, but every Metabase environment operated by you or by a service provider – especially if it is reachable from the internet. In its data, Wiz observed that around 13% of cloud environments used self-hosted Metabase, and of those roughly 25% were fully reachable from the internet. Via the search service Shodan, around 2,500 Metabase instances were inventoried on the internet. Important: this figure describes only reachable systems – not confirmed vulnerable or compromised instances. Neither Metabase nor CISA nor the BSI has published a verified total number of compromised organisations or leaked datasets.
That the attacks are real is shown by the first incidents to become public: the service n8n reported on 11 August 2026, forensically confirmed, 7 records with cloud usernames and email addresses, as well as 5 records with name, cloud username, email address and a bcrypt password hash; a further 62 records with names and email addresses may be affected. Kilo Code/Anaconda reported an incident on 2 August 2026 that lasted about four hours and in which, among other things, prompts, name, email, billing address, location and – for a subset – Slack access tokens may have been affected.
A note of caution: a mere version check, or the absence of the log pattern mentioned, does not necessarily rule out other traces of an attack. Where there is suspicion, treat the case as a security incident.
Note: this is a general assessment and not legal advice.
A successful, or sufficiently concretely suspected, access to personal data via Metabase may constitute a personal data breach within the meaning of Art. 4(12) GDPR. In that case, controllers must, under Art. 33 GDPR, report to the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware – unless the breach is unlikely to result in any, or in only a low, risk to the rights and freedoms of the data subjects. Where the report is made later, the delay must be justified. Even where no report is made, there is a documentation obligation (Art. 33(5)). Processors must inform the controller without undue delay. Where there is likely to be a high risk to data subjects, notification under Art. 34 GDPR must additionally be considered.
Depending on the connected data sources, contact, customer, usage, address or analytics data, as well as credentials, may be affected here. That is why data categories, scope, actual access, protective measures and consequential risks must be assessed on a case-by-case basis. A reporting obligation does not arise merely because of an unpatched version, but on the basis of an actual data protection breach and the risk assessment. The n8n example shows that, following forensic analysis, a company both contacted the affected individuals and informed the Berlin data protection authority.
Fines cannot be forecast across the board: Art. 83 GDPR requires an assessment that is case-specific, effective, proportionate and dissuasive. The range for infringements of the security of processing (Art. 32) runs up to EUR 10 million or 2% of global annual turnover, and for certain infringements of fundamental principles up to EUR 20 million or 4%. As a – not directly comparable – reference case, the official British Airways decision from 2020 documents a fine of GBP 20 million for inadequate security; decisive there were, among other things, the nature, gravity and duration, the number of data subjects, protective measures, remediation and cooperation.
CVE-2026-72898 is a serious case: highest criticality (CVSS 10.0), attack without authentication and without user interaction, confirmed active exploitation, inclusion in the CISA KEV catalogue, a BSI warning and publicly available exploit tools. Anyone operating a self-hosted Metabase instance should not wait now.
The good news: there are patches for all supported version branches, and Metabase Cloud has already been updated. Act in this order: find your instances, check the version, patch immediately, check the reachability of the reset endpoint, search logs for the 400/200 indicator, revoke sessions, clean up API keys, rotate database credentials – and, if you suspect data access, check your GDPR obligations. And even if you do not run Metabase yourself: clarify explicitly with your web, shop, hosting, agency or analytics service providers whether a Metabase instance is running there on your behalf. A prompt update costs you a few minutes today – an overlooked access path can cost you far more later.