Metabase just confirmed something no analytics vendor wants to write: attackers found and used an unpatched, maximum-severity flaw against Metabase Cloud before anyone on the defense side knew it existed. The company’s own advisory says the vulnerability carries a CVSS score of 10.0, and it let an unauthenticated attacker inject arbitrary SQL straight into the Metabase application database.
“We recently identified that Metabase Cloud was attacked by someone utilizing an unknown (“0-day”) security vulnerability in versions 1.58 and above.” reads the advisory. “We immediately blocked the endpoints used for the attack, then quickly identified and patched the vulnerability.”
Metabase is an open-source business intelligence (BI) and data analytics platform. It allows companies to connect databases and turn their data into dashboards, charts, reports, and queries without requiring users to write complex SQL.
That access is just the starting point. Once inside, the attacker could grab administrator rights over the whole instance, then pivot from there: changing application configuration, stealing stored credentials for every connected database, reading whatever data those connections could reach, and pulling it all out. For a business intelligence tool that’s typically plugged into a company’s most sensitive data warehouses, that’s close to a worst-case blast radius.
Metabase Cloud customers didn’t have to lift a finger. The company detected the attack, blocked the endpoint being abused, and patched it before most users even knew there was a problem, and cloud instances were already running the fixed version by the time the advisory went public. Self-hosted deployments are a different story entirely, and anyone running their own instance on an affected version needs to treat this as urgent, not routine.
“If you are self-hosting Metabase, your instance of Metabase may be vulnerable. After gaining access to your instance, the attacker could inject arbitrary SQL against the Metabase application database, which can give them administrator access to the instance.” continues the advisory. “From there, the attacker could change your application configuration, steal stored credentials for your connected databases, read any data accessible through those connections, and export data. For more information, see the security advisory.”
The affected range spans versions 58 through 63, with a specific patched point release for each: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5. Anyone on version 57 or earlier is in the clear, according to Metabase, but everyone else running an older point release on those six branches needs to update immediately. If an upgrade can’t happen right away, Metabase’s stopgap is blocking the /api/session/reset_password
endpoint at the network level until the patch lands.
Metabase also published a specific attack signature worth checking logs against right now. “call to POST /api/session/reset_password with a 400 status code followed by call to GET /api/user/current with a 200 status code” is the pattern the company says indicates compromise, and if that sequence shows up in application or ingress logs, treat the instance as breached rather than merely exposed.
For anyone who’s had that reset-password endpoint publicly reachable, the cleanup list is longer than a simple patch. Metabase recommends wiping every active session by clearing the core_session
table, auditing API keys for anything unrecognized, checking administrator accounts for unexpected changes, rotating credentials on every connected database, and combing through both data warehouse logs and Metabase’s own query history for signs someone poked around where they shouldn’t have.
At least one real-world casualty has already surfaced. PC maker Framework confirmed it was hit through this flaw, notifying customers that names, login IPs, addresses, phone numbers, and email addresses were accessed during the breach, though the company said no order or payment information was touched. A dashboard tool getting popped rarely makes headlines on its own, but when it sits between attackers and a company’s actual customer database, the headline writes itself.
The uncomfortable part of this story isn’t the CVSS score, it’s the timeline. This was exploited as a genuine zero-day, meaning real attackers found the flaw before Metabase did, and the company only learned about it because it was already being used against Metabase Cloud itself.
If you’re running Metabase self-hosted and haven’t checked your version number yet, this is the moment to stop reading and go check it.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Metabase zero-day)