Short version: a nasty SQL injection bug in Metabase was weaponized in the wild, letting attackers poke around customer instances and nick data. The vendor patched Cloud instances quickly and released fixes for self-hosted installs — but some customers still had their info taken before the bandaid went on.

What happened (and why it’s a big deal)

Metabase discovered an unauthenticated SQL injection flaw that could let a remote attacker inject SQL into the application database and escalate all the way to administrator access. That’s not just annoying — once an attacker gets admin rights they can change settings, grab stored database credentials, read connected data, and export anything they can reach.

The company says the problem was actively exploited against Metabase Cloud and that self-hosted deployments running vulnerable versions were also at risk. Metabase blocked the attack endpoints and rolled out a fix for Cloud customers, but self-hosted users must update themselves.

The issue was rated Critical with a perfect severity score of CVSS 10.0, and patched releases were published for the affected branches. If you run Metabase, the minimum safe releases are:

  • 0.58.24
  • 0.59.21
  • 0.60.17
  • 0.61.11
  • 0.62.9
  • 0.63.5

If you can’t patch immediately, a temporary stopgap is to block access to the /api/session/reset_password endpoint until you can update.

Who was impacted and what you should do (quick checklist)

Several organizations confirmed data exposure after their Metabase instances were hit. Reported impacts include theft of customer names, emails, billing and shipping addresses, phone numbers, IPs used for logins, and business identifiers (VAT/EIN) for some corporate customers. Some services also reported that hashed passwords were accessible from the compromised analytics environment — hashes are one-way, but they’re not something you want leaking.

How to respond if you run Metabase (or if you’re a customer worried your provider was hit):

  • Upgrade immediately to one of the patched releases listed above.
  • Temporarily block /api/session/reset_password if you cannot upgrade right away.
  • Revoke all active user sessions and review admin accounts for unauthorized changes.
  • Inspect API keys, webhooks and admin settings for anything unfamiliar.
  • Rotate database credentials and any secrets stored in Metabase — rotate credentials now.
  • Check logs and query history for suspicious activity. One telltale sign is a failed POST to /api/session/reset_password returning 400, followed by a successful GET to /api/user/current.
  • If you suspect compromise, bring in forensics and notify affected users as required by law or policy.

Yes, this one stings. Treat Metabase analytics instances like part of your attack surface: keep them patched, monitor access, and don’t let forgotten tools become backdoors. If you need to calm an upset stakeholder, the short script is: patch, revoke sessions, rotate secrets, and investigate.