Metabase Zero-Day Flaw Exploited in the Wild Grants Attackers Full Admin Access Without a Password

A maximum-severity vulnerability in Metabase's business intelligence software is being actively exploited in the wild, allowing unauthenticated attackers to seize full administrator control of affected instances and steal sensitive data.

The flaw carries a perfect CVSS score of 10.0 and has already compromised multiple companies including Framework, n8n, and Kilo Code. With no CVE identifier assigned yet, the vulnerability underscores a growing reality in enterprise software security: the tools organizations use to visualize and manage their most sensitive data can become the very doorway attackers walk through. Understanding how to prevent and respond to zero-day attacks has never been more critical for security teams managing business intelligence platforms.

---

What the Vulnerability Does and Who Is Affected

The flaw enables an unauthenticated remote attacker to inject arbitrary SQL directly into the Metabase application database. Once inside, the attacker gains administrator-level access to the entire instance without ever needing a valid username or password.

With that elevated access, a threat actor can:

• Change application configurations
• Steal stored credentials for connected databases
• Read and export any accessible data freely

The attack surface is broad and the consequences immediate.

Metabase confirmed the exploitation in an advisory, stating: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability in versions 1.58 and above."

Affected Versions and Patch Status

The affected version ranges span a wide swath of deployments. Any installation running versions from x.58.0 through x.63.3 that has not yet applied the corresponding patches remains at risk. Metabase Cloud instances have already been updated automatically. Self-hosted users must act immediately.

The fixed versions are:

• x.58.24
• x.59.21
• x.60.17
• x.61.11
• x.62.9
• x.63.5

For organizations that cannot patch immediately, Metabase advises blocking the /api/session/reset_password endpoint as a temporary workaround. This mitigation does not replace patching but reduces the immediate attack surface while remediation is prepared.

Why Business Intelligence Tools Are High-Value Targets

This incident reflects a broader and underappreciated threat pattern. Business intelligence platforms like Metabase occupy a uniquely dangerous position in the enterprise stack — they hold connection strings, stored credentials, and query history that touch virtually every system across an organization's environment. Attackers who compromise a BI tool do not just gain access to dashboards; they gain a map of the entire data infrastructure.

Treating internal analytics tools as inherently low-risk is a security posture that organizations can no longer afford. Applying robust identity and access management best practices to every layer of the data stack — including reporting and visualization tools — is now a baseline expectation, not an advanced measure.

---

Real-World Victims and the Breach Trail

The exploitation was not theoretical. Several companies confirmed they were directly impacted by the zero-day attacks, each disclosing meaningful exposure of customer data.

Framework

PC maker Framework notified all customers that names, login IP addresses, physical addresses, phone numbers, and email addresses were accessed during the breach. The company confirmed no order or payment information was compromised. While the scope of personal data is significant, the absence of financial records offers limited reassurance given the value of physical addresses and contact details for downstream phishing and social engineering campaigns.

n8n

Workflow automation platform n8n disclosed on August 8, 2026, that an attacker accessed 136 customer records containing names and email addresses for both self-hosted and n8n Cloud users. Five of those records contained bcrypt-hashed passwords belonging to n8n Cloud accounts.

"Our investigation confirmed that an unauthorized third party accessed and queried certain data available through n8n's Metabase environment," the company stated. Because the attacker's queries returned variable results each time, n8n said it cannot determine precisely which records were accessed.

N8n's investigation also surfaced an unrelated historical bug fixed in April 2023 that had caused a small number of n8n Cloud account passwords to be stored in plain text. While no evidence links those records to the Metabase exploitation, n8n contacted all 25 affected account holders directly and notified relevant data protection authorities.

Kilo Code

Kilo Code, a third confirmed victim, reported that the breach "occurred over a period of approximately four hours on August 2, 2026" and that it was not alerted until four days later. The company confirmed its Kilo Slackbot was compromised and that a subset of users had their Slack access tokens exposed. All affected authentication tokens were invalidated and impacted users were notified directly.

The four-day detection gap at Kilo Code highlights a detection and alerting problem that extends beyond the vulnerability itself. Even where patches exist, slow incident identification dramatically widens the window of damage.

---

How to Detect a Compromise and What to Do Next

Metabase CEO Sameer Al-Sakran provided specific indicators of compromise that administrators can use to determine whether their instance has been targeted.

"If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised," Al-Sakran said.

Indicators of Compromise to Watch For

The specific log pattern to identify is:

• A call to POST /api/session/reset_password returning a 400 status code
• Immediately followed by a call to GET /api/user/current returning a 200 status code

This sequence indicates a successful authentication bypass. Any organization that identifies this pattern should treat the instance as compromised and begin incident response immediately, regardless of whether a patch has been applied.

Post-Incident Remediation Checklist

For any organization that finds those indicators or has already applied patches, Metabase recommends a thorough post-incident review:

1. Revoke all active user sessions by deleting all rows in the core_session table
2. Review and delete any unrecognized API keys
3. Audit administrator accounts for unexpected changes
4. Rotate credentials for all connected databases
5. Review data warehouse logs for unauthorized access
6. Examine Metabase activity and query history for suspicious queries

Strengthening Authentication Across the Stack

Beyond the immediate remediation steps, this incident reinforces why layered authentication controls matter across all internal tools. Implementing multi-factor authentication across business applications adds a meaningful barrier that can limit attacker progression even when an application-layer vulnerability exists. MFA alone would not have prevented this specific attack vector, but it forms part of a defence-in-depth posture that reduces the blast radius of credential theft and session hijacking resulting from breaches like this one.

A Pattern of Critical Severity

This is not the first time Metabase has faced a critical vulnerability of this severity. Exactly three years earlier, the company patched CVE-2023-38646, a flaw rated 9.8 on the CVSS scale that could have allowed pre-authenticated remote code execution on affected installations. The recurrence of near-identical risk profiles raises serious questions about the security review processes surrounding Metabase's authentication and session management architecture.

For deeper context on how this vulnerability class compares to prior disclosures, the National Vulnerability Database entry for CVE-2023-38646 provides technical detail on the earlier flaw and its remediation history.

The pattern is difficult to dismiss. Two critical, pre-authentication vulnerabilities within three years — both targeting session management — suggest that architectural hardening, not just patching, is the appropriate long-term response.

For security teams and IT administrators, the Metabase zero-day is a stark reminder that business intelligence tools sit at the intersection of data access and organizational trust. They hold credentials, connection strings, and query history that touch virtually every system in an enterprise environment. Treating them as low-risk internal tools is no longer defensible.

Organizations running self-hosted Metabase instances should patch immediately and treat any unpatched deployment as potentially compromised. For businesses evaluating data visualization platforms, this incident reinforces the value of vendor transparency in vulnerability disclosure and the importance of runtime access controls that limit what even authenticated administrator sessions can reach.