A critical 0-day security vulnerability has been discovered in Metabase versions 1.58 and above, actively exploited against Metabase Cloud. The vulnerability allows attackers to inject arbitrary SQL against the Metabase application database, potentially granting administrator access, stealing stored database credentials, and exporting data. Metabase Cloud instances are already patched. Self-hosted users must immediately upgrade to the minimum safe release for their version branch (0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5). The attack pattern involves a POST to /api/session/reset_password returning 400 followed by a GET to /api/user/current returning 200. If the reset_password endpoint is publicly accessible, users should also run TRUNCATE TABLE core_session after upgrading. As a temporary workaround, blocking the /api/session/reset_password endpoint is recommended if immediate upgrade is not possible.
Table of contents
Immediate steps to takeAttack patternUpgrade instructionsMinimum safe releases for each Metabase versionWorkaround: temporarily block the affected endpointQuestions this post answers
What versions of Metabase are affected by the critical 0-day SQL injection vulnerability?
Metabase versions 1.58 and above are vulnerable. The minimum safe releases are: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5. Versions below 58 are not affected. Metabase Cloud instances were patched automatically. The vulnerability allows arbitrary SQL injection against the application database, potentially granting attacker administrator access and the ability to steal stored database credentials. Teams running self-hosted Metabase can track patch advisories like this one on daily.dev before they become incidents.
How can I tell if my self-hosted Metabase instance was compromised by the reset_password exploit?
Look in your application logs or Metabase server ingress logs for this pattern: a POST to /api/session/reset_password returning a 400 status code, immediately followed by a GET to /api/user/current returning a 200 status code. If that sequence appears, your instance is likely compromised. After upgrading, if the reset_password endpoint was publicly accessible, run TRUNCATE TABLE core_session to invalidate all sessions. Security incidents in self-hosted analytics tools surface fast on daily.dev — worth watching if you manage your own Metabase.