This order of operations is all there is to it. There were no patches to slip through the cracks, and there were no advisories to be ignored. It was truly a zero-day vulnerability and discovered in the same fashion as any other by attack.
What is the Metabase zero-day? An unauthenticated SQL injection vulnerability identified as GHSA-vwf4-m7j8-wcjf and classified as CVSS 10.0. It allows a remote attacker to inject arbitrary SQL commands into the Metabase application database, allowing them to gain administrator access to the instance. It does not require any credentials and user interaction.
Two Requests, Then Administrator Access
The attack itself is relatively simple and involves only two HTTP requests.
A POST to /api/session/reset_password endpoint, which results in 400 response. Then comes GET request to /api/user/current. This combination of events is the full signature of the exploit.
There is nothing about this flow that could be deemed malicious while observing it from outside. Both endpoints are legitimate and present in every standard Metabase instance. Failed password reset and subsequent session check are common actions in any web application.
The simplicity is significant because of its scalability. An exploit that requires no authentication, no chaining, and no special tools can be executed against all accessible instances instantly. Metabase explicitly stated that their cloud environment was attacked using an unknown vulnerability.
Three Named Victims, Three Different Losses
The modular laptop producer, Framework, suffered from the largest loss of customer data. The list of data types compromised includes full names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. For business customers, the data included VAT and EIN numbers.
Tally is an online forms builder, and the attacker accessed its analytics environment on the same day. The company lost user email addresses and one-way hashed passwords. However, forms and form submissions were kept separately and remained safe.
It seems that LexisNexis‘ Metabase API was accessed via compromised servers of a third party vendor. The systems were disconnected by LexisNexis. Data leaks have not been confirmed yet.
Three companies, three architectures, one common component. Neither party claimed these attacks, nor any ransom demand appeared yet.
Why Metabase Is a High-Value Target
The Only Evidence Was A Failed Password Reset
The intrusion did leave its mark. That particular request combination appears in log files, in plaintext, in all of the instances affected.
Finding it involved knowing where to look. This wasn’t done before August 6, when the advisory became public. Metabase had already contacted impacted organizations one day prior to this date.
Over the course of these four days, traffic was completely normal and the application functioned normally. The only unusual occurrence was a password reset failure.
Patching Alone Does Not Close This One
Metabase deployed the necessary patches in release lines 58 through 63 and auto-updated its cloud tenants. For self-hosting deployments, the patch must be applied manually by the administrators.
The patch prevents the next attack but does not remedy the consequences of the previous one. The attacker who possesses administrative access to the Metabase instance can access the connection credentials of all databases connected to it.
Thus, the compromise might not stop at Metabase. It stops at where the credentials are still functional. Changing the credentials is a task that is separate from patching the application and is one that often gets quietly overlooked.
The shape is familiar. In July we covered a Fastjson zero-day under active exploitation with no fix available at all. Metabase at least produced a patch within days. What both cases share is defenders arriving after the fact, responding to something that had already finished running.
Conclusion: The Patch Closed the Flaw. It Did Not Revoke the Keys.
Metabase was exploited before defenders had an advisory, a signature, or a fixed release.
The attack required no credentials and no user interaction. Two requests that could resemble ordinary application activity were enough to turn public access into administrator control. The application could continue operating normally while the attacker gained access behind the dashboard.
The greater risk was not Metabase alone. The platform sits between users and connected databases, storing the credentials required to query them. Once administrator access is established, the compromise can extend wherever those credentials remain valid.
Why This Threat Matters
- The first attacks occurred before a patch was available.
- The exploit required no authentication or user decision.
- Legitimate application endpoints made the visible request sequence difficult to distinguish from normal traffic.
- One Metabase instance may hold access to several databases and data warehouses.
- Administrator access can expose configuration, API keys, stored credentials, query history, and connected data.
- Updating the application does not invalidate previously stolen sessions or database credentials.
- The downstream impact ends only where the attacker’s recovered access stops working.
The absence of malware does not reduce the severity. In this case, trusted application functionality provided the path from a web request to multiple data sources.
Where Defensive Control Must Operate
The immediate control belongs at the application and exposure layers.
Xcitium Vulnerability Assessment supports the post-disclosure response by identifying reachable self-hosted Metabase deployments, affected versions, missing updates, and instances that have not reached a fixed release.
It cannot retroactively identify an undisclosed zero-day or prove that a patched system was never exploited. Version remediation and compromise assessment remain separate tasks.
Execution Governance is secondary in this incident. If follow-on activity introduces unknown scripts, tools, or payloads onto a supported Metabase host, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, can govern that unknown execution before it receives unrestricted access to real system resources.
It does not block the original SQL injection through the trusted application process, and it does not replace session revocation or database credential rotation.
Patch the Instance. Revoke the Reach.
Recovery is not complete when the Metabase version number changes.
Active sessions must be invalidated. API keys and administrator accounts must be reviewed. Credentials for every connected database must be rotated. Metabase activity, query history, and data warehouse logs must be examined for unauthorized access.
The objective is not merely to close the SQL injection.
It is to remove every privilege that may have escaped through it.
