Of the three vulnerabilities CISA added to its Known Exploited Vulnerabilities catalogue on 11 August, the Metabase entry got the least coverage and arguably deserved the most.
CISA's description:
Metabase contains a SQL Injection vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance.
Remediation deadline: 14 August — three days from listing.
Why business intelligence is a soft target
Metabase is a self-hosted analytics front end. Organisations point it at their data warehouse, connect it to production replicas, and give it read credentials for whatever people need to report on. Then they put it behind a login and stop thinking about it.
That architecture means a Metabase instance is rarely interesting for its own data. It is interesting because of what it is connected to. An administrator on the instance can typically:
- read every saved question and dashboard, which is a map of what the business measures
- enumerate every configured database connection
- create new queries against those connections
- in many deployments, reach data the compromised account was never meant to see, because the connection credentials belong to Metabase rather than to the user
The SQL injection lands in Metabase's own application database. Administrator access is the first step, not the last.
Unauthenticated is the word that matters
Plenty of SQLi findings require a session. This one does not. An attacker who can reach the HTTP endpoint can reach the bug, which collapses the exploitation path to: find an exposed instance, send the request.
Shodan-style discovery of self-hosted BI tools is neither difficult nor novel. If your Metabase is internet-facing, assume it has been found.
What to do
Patch to a fixed release. Check your exact version against Metabase's own security advisories rather than a summary.
Then assume compromise and check. A patch closes the hole; it does not tell you whether someone came through it first. Worth reviewing:
- new or modified admin accounts
- new database connections, especially ones pointing somewhere unexpected
- unfamiliar saved questions, particularly ones that read from system tables
- outbound connections from the Metabase host that do not match its normal pattern
Rotate the database credentials Metabase holds. If the instance was reachable and unpatched, those credentials should be treated as exposed regardless of what the logs show.
Then ask why it was reachable. A reporting tool almost never needs to accept connections from the public internet. Putting it behind a VPN or identity-aware proxy removes this entire class of finding from your exposure, not just this CVE.