The dashboard tool with your database password
Somewhere in your business there is probably a reporting dashboard. Someone set it up a year or two ago so the team could see sales figures without asking anyone, and it has quietly worked ever since.
To draw those charts, it holds a working login to your live database. Not a copy, not an export: the real thing, saved inside the tool so it can run a query whenever somebody opens a page.
That makes it one of the most valuable things you run, and it is often the one nobody has thought about since the day it was installed.
What happened
Metabase is a widely used tool of exactly this kind, available both as a hosted service and as software you run yourself. On 6 August it disclosed that its hosted platform had been attacked through a flaw nobody knew about, and that self-hosted installations were vulnerable too.
The company's advisory describes an unauthenticated SQL injection flaw. In plain terms: an attacker who had never logged in, and needed no password, could send the tool a crafted request and end up with administrator control of it. Metabase rates it critical, at 10.0 on the standard severity scale. That scale runs to 10.
Severity scores are often worth arguing with. This one is not. It needs no privileges, no user interaction, and can be reached across the network, and Metabase has confirmed it was being exploited before anyone knew it existed. On this occasion the headline number and the real risk agree.
What the attacker gets is the point. Metabase's own description: change the application configuration, steal the stored credentials for the connected databases, read anything reachable through those connections, and export it. The dashboard is not the prize. The saved database logins are.
That is not hypothetical. The laptop maker Framework has told customers that attackers reached its Metabase instance on 3 August and took names, email addresses, login IP addresses, billing and shipping addresses, phone numbers, and company names. The form builder Tally has told users the same thing happened to its analytics environment, exposing email addresses and hashed passwords. LexisNexis disconnected from a third-party vendor's systems over what it described as unusual activity affecting its Metabase API.
What to do this week
If you run Metabase yourself, this is a today job rather than a this-month job.
Check your version. Anything from 1.58 upwards is affected. Versions below 58 are not. Metabase has published the minimum safe release for each branch: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5. A point release below the one for your branch is still vulnerable. If you use the hosted version, Metabase says its customers were upgraded already.
Assume compromise until you have looked. Patching now does not undo access someone already had. Metabase's guidance is to revoke every active session, review your API keys for any you do not recognise, check administrator accounts for unexpected changes, and rotate the credentials for every connected database. That last one matters most, because stolen database logins keep working after the tool is fixed.
Look for the pattern in your logs. Metabase says an attack looks like a POST request to /api/session/reset_password returning a 400, followed straight after by a successful GET to /api/user/current. If you find that, treat the instance as compromised. Worth knowing that Metabase warns the logs themselves may have been tampered with.
If you cannot patch immediately, Metabase suggests blocking outside access to that reset_password endpoint as a stopgap. A stopgap is not a fix.
If somebody else runs this for you, those are the questions to put to them, in that order.
The wider question this raises
Most businesses can list the systems that obviously hold customer data. The finance system, the CRM, the website. Fewer can list the things that hold a key to those systems: the reporting tool, the backup job, the integration somebody set up to sync two products together.
Every one of those holds credentials, and each is a way to the data without touching the system that stores it. They tend to be installed by whoever needed them, for a good reason, and then left running.
Two questions worth an hour of somebody's time. Which tools in this business hold a saved login to a system that matters? And when one of them needs patching, whose job is that?
The Framework case has an uncomfortable footnote. Their customers, discussing the breach on Framework's own community forum, largely praised the speed and honesty of the notification: Metabase told them on 6 August, and they told customers within hours. But several made a sharper point. Framework's notice said it was "evaluating the breadth and depth of data shared with business intelligence platforms, and scoping down their access to only the columns required for analysis". As one customer put it, that is the right direction, and it suggests the tool had more than it needed in the first place.
Reporting tools tend to get pointed at whole tables because that is easier than deciding which columns matter. It works fine right up until the moment somebody else is reading them.
How Steelwise can help
Working out what is connected to your data, what credentials each thing holds, and who is responsible for keeping it patched, is a defined piece of work with a clear answer at the end. Get in touch if you want a second opinion on yours.
Further reading
- Metabase's security advisory with version numbers and the full checklist
- NCSC guidance on vulnerability management
- NCSC guidance on asset management, on knowing what you actually run