Metabase has warned that a maximum-severity security flaw impacting its business intelligence and data visualization software has been exploited in the wild as a zero-day.
The vulnerability allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, enabling them to gain administrator access to the instance.
The Metabase zero-day vulnerability carries a CVSS score of 10.0. It does not currently have a CVE identifier. Armed with elevated access, the attacker can change the application configuration, steal stored credentials for connected databases, read any data accessible through those connections, and export data.
Let me walk through the Metabase zero-day vulnerability, what it means for users, and what you need to do.
What Is the Metabase Zero-Day Vulnerability?
The Metabase zero-day vulnerability allows an unauthenticated attacker to inject arbitrary SQL into the Metabase application database. This gives the attacker administrator access to the instance.
" We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability in versions 1.58 and above," Metabase said in an advisory.
With administrator access, the Metabase zero-day vulnerability enables several malicious actions. The attacker can change application configuration, steal stored credentials for connected databases, read any data accessible through those connections, and export data.
The CVSS score of 10.0 reflects the maximum severity of the Metabase zero-day vulnerability. It requires no authentication and provides full administrative control.
Metabase Cloud Already Patched
Metabase Cloud instances have already been updated to the latest version. The company acted quickly to protect its cloud customers from the Metabase zero-day vulnerability.
However, users running self-hosted versions are at risk. They must apply security patches released by Metabase with immediate effect. The Metabase zero-day vulnerability affects a wide range of self-hosted versions.
Affected Versions and Fixes
The Metabase zero-day vulnerability affects the following versions:
- = x.58.0, < x.58.23 (Fixed in x.58.24)
- = x.59.0, < x.59.20 (Fixed in x.59.21)
- = x.60.0, < x.60.16 (Fixed in x.60.17)
- = x.61.0, < x.61.10 (Fixed in x.61.11)
- = x.62.0, < x.62.8 (Fixed in x.62.9)
- = x.63.0, < x.63.3 (Fixed in x.63.5)
If you are running any self-hosted version within these ranges, you are vulnerable to the Metabase zero-day vulnerability and need to patch immediately.
Temporary Workaround
If you cannot patch immediately, Metabase has provided a temporary workaround for the zero-day vulnerability. "/api/session/reset_password" endpoint needs to be blocked . This will make sure that the attack vector for the Metabase zero-day vulnerability is used.
Once the update is done, customers having the "/api/session/reset_password" endpoint exposed to the public need to do:
- First, revoke all active user sessions by accessing the Metabase Application Database and deleting all rows in the core_session table. This will ensure that all the attacker’s sessions get terminated.
- Second, verify the API keys and remove all unknown keys because the Metabase zero-day vulnerability may have been exploited to create unauthorized API keys.
- Third, verify any unexpected changes to the administrator account. The attacker might have changed something within the current admin account.
- Fourth, rotate credentials of all databases which are connected to it. There is a Metabase zero-day vulnerability which might have exposed stored credentials.
- Fifth, check the data warehouse logs to identify any unauthorized access. The attacker may have accessed the data.
- Finally, review Metabase activity and query history for unexpected or unauthorized activity.
The Framework Data Breach
One of the companies affected by the Metabase zero-day vulnerability is Framework. According to Engadget, the PC maker alerted all its customers that customer names, login IPs, addresses, phone numbers, and emails were accessed during the hack.
Framework noted that no order or payment information was accessed. However, the exposure of customer names, addresses, phone numbers, and emails is still significant. It can also be used in phishing attacks or social engineering.
The Framework breach demonstrates the real-world impact of the Metabase zero-day vulnerability. Organizations using self-hosted Metabase are at risk of similar data exposure.
Indicators of Compromise
Metabase has shared specific indicators of compromise for the zero-day vulnerability. Look for a call to "POST /api/session/reset_password" with a 400 status code. This is followed by a call to "GET /api/user/current" with a 200 status code.
"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," Metabase CEO Sameer Al-Sakran said.
These IoCs are critical for identifying whether your instance has been affected by the Metabase zero-day vulnerability. Review your logs immediately.
A History of Metabase Vulnerabilities
The Metabase zero-day vulnerability is not the first critical flaw to affect the platform. Exactly three years ago, Metabase addressed another "extremely severe" flaw tracked as CVE-2023-38646. That vulnerability carried a CVSS score of 9.8 and could have resulted in pre-authenticated remote code execution on affected installations.
Vulnerabilities that keep coming up within Metabase indicate the need for quick patching and security monitoring. All organizations utilizing Metabase need to be up-to-date with security updates.
What This Means for Defenders
The Metabase zero-day vulnerability requires immediate action from organizations using self-hosted instances. The vulnerability is being actively exploited in the wild. Metabase Cloud is already patched, but self-hosted users must act.
If you are running a vulnerable version, apply the patch immediately. In case of any difficulty in patching, you may need to block the "/api/session/reset_password" path as an interim solution.
Check the logs for the IoCs. In case you observe the pattern, it means that your instance is compromised and follow the remediation steps.
The Metabase zero-day vulnerability is a reminder that even widely used business intelligence tools can be targeted. Ensure your security remains tight and patch your system.
Conclusion
The zero-day Metabase vulnerability represents a serious security flaw as it gives unauthenticated attackers administrative privileges. The vulnerability carries a CVSS score of 10.0 and has been exploited in the wild.
Metabase Cloud instances are already patched. Self-hosted users must apply updates immediately. Versions x.58.0 through x.63.3 are affected.
Framework is one company that has already been impacted by the Metabase zero-day vulnerability. Customer names, addresses, phone numbers, and emails were exposed.
Block the "/api/session/reset_password" endpoint as a temporary workaround. Review your logs for the IoCs. If compromised, revoke sessions, review API keys, rotate credentials, and audit activity.
The Metabase zero-day vulnerability is a clear and present danger. Patch now.
FAQ Section
What is the Metabase zero-day vulnerability?
It is a critical SQL injection flaw that allows unauthenticated attackers to gain administrator access to Metabase instances. The vulnerability carries a CVSS score of 10.0 and has been exploited in the wild.
Which Metabase versions are affected?
Versions x.58.0 through x.58.23, x.59.0 through x.59.20, x.60.0 through x.60.16, x.61.0 through x.61.10, x.62.0 through x.62.8, and x.63.0 through x.63.3 are affected.
What should I do if I use self-hosted Metabase?
Patch these vulnerabilities right away. If that's not possible, you can block the endpoint “/api/session/reset_password” as a temporary solution. Look out for any IoCs in your logs.
What data was exposed in the Framework breach?
Framework reported that customer names, login IPs, addresses, phone numbers, and emails were accessed. No order or payment information was exposed.
What are the signs of compromise?
There should be a request to “POST /api/session/reset_password” with a 400 status code followed by “GET /api/user/current” with a 200 status code. This signifies probable compromise.
