Critical Metabase Vulnerability Exploited to Gain Admin Access

Key Takeaways

• A critical zero-day vulnerability (GHSA-vwf4-m7j8-wcjf) in Metabase, a popular business intelligence platform, is being actively exploited.
• The flaw allows unauthenticated attackers to gain full administrator access through an SQL injection in the password reset function.
• All Metabase versions from 0.58 through 0.63 are affected, with a maximum CVSS score of 10.0.
• While Metabase Cloud instances were automatically patched, self-hosted deployments require immediate manual updates.
• Evidence of exploitation includes specific log patterns, and two companies have already reported data theft.

Critical Metabase Vulnerability Exploited to Gain Admin Access

Metabase, the widely utilized open-source platform for business intelligence and data visualization, has confirmed active exploitation of a severe zero-day vulnerability. Identified as GHSA-vwf4-m7j8-wcjf, this flaw enables attackers to bypass authentication and achieve complete administrator privileges on affected instances.

The vulnerability, which currently lacks a CVE identifier but carries a maximum CVSS score of 10.0, impacts all Metabase releases from version 0.58.0 up to and including 0.63.x. Its confirmed real-world exploitation and critical severity position it as one of the most significant business intelligence platform vulnerabilities disclosed this year.

Understanding the Attack Vector

The core of the vulnerability lies in an unauthenticated SQL injection flaw accessible via the public POST /api/session/reset_password endpoint. This allows an attacker to inject arbitrary SQL statements directly into the Metabase application database without needing any prior authentication.

Upon successful injection, the attacker can manipulate database records to elevate their privileges to an administrator account, thereby gaining full control over the Metabase instance. This level of access grants the attacker the ability to modify application configurations, extract stored credentials for all connected databases, read any data accessible through those connections, and export sensitive records at will.

Metabase first detected the abuse on August 3, when its own Metabase Cloud SaaS platform experienced a breach. Attackers leveraged the previously unknown flaw to compromise customer instances. In response, the company swiftly blocked the malicious endpoints and deployed a patch within hours, automatically upgrading and securing all Metabase Cloud customers.

However, organizations running self-hosted Metabase deployments remain vulnerable until administrators manually apply the necessary fixes. Already, at least two companies, Framework and Tally, have reported data theft incidents linked to this zero-day. These incidents involved unauthorized access to customer information, including names, addresses, phone numbers, and email addresses.

Identifying and Mitigating Exploitation

Defenders can identify potential exploitation by looking for a specific attack signature in their web server or application logs. This pattern involves a POST /api/session/reset_password call returning a 400 status code, immediately followed by a GET /api/user/current call returning a 200 status code. This sequence indicates a successful exploit chain resulting in an authenticated session, and any instance exhibiting these log entries should be considered compromised.

Business intelligence tools like Metabase are often central to an organization’s data infrastructure, frequently holding privileged credentials to multiple backend databases. This makes a single unauthenticated SQL injection flaw exceptionally dangerous, as compromising one BI instance can lead to a much larger breach of interconnected systems.

What You Should Do

Organizations running self-hosted Metabase instances must take immediate action:

• Upgrade Immediately: Update to the minimum safe patched release for your Metabase branch without delay. These include 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5. Versions older than 0.58 are not affected by this specific vulnerability.
• Assume Compromise if Log Pattern Appears: If the password reset endpoint was publicly accessible prior to patching, and the distinctive log pattern (400 on /api/session/reset_password followed by 200 on /api/user/current) is present, assume your instance has been compromised.
• Revoke Sessions: Clear the core_session table to invalidate all active sessions.
• Audit API Keys: Review all API keys for any unrecognized or unauthorized entries.
• Review Administrator Accounts: Scrutinize administrator accounts for any unexpected changes or additions.
• Rotate Credentials: Change credentials for all databases connected to Metabase.
• Review Logs: Thoroughly examine data warehouse and Metabase query logs for any signs of unauthorized activity.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.