**TL;DR - CVE-2026-72898 (CVSS 10.0, unauthenticated SQL injection via /api/session/reset_password) has been on CISA's Known Exploited Vulnerabilities catalog since 2026-08-11. N8n and Kilo Code are the latest named victims, joining Framework, Tally, and LexisNexis. If you run self-hosted Metabase 0.58 through 0.63, assume you were scanned. What you need to do: audit every Metabase instance you know about, and every one you have forgotten about - because your finance team probably spun one up two years ago and never told you.
It is August 15, 2026. The Metabase advisory dropped nine days ago. If you work in an SMB or MSP and you have not touched your Metabase instances yet, this post is for you.
The week-two view
The original disclosure on 6 August was fast: GHSA published, patches released, Hacker News covered it within 48 hours. By 11 August, CISA had added CVE-2026-72898 to its Known Exploited Vulnerabilities catalog. The federal due date is 14 August. By the time you read this, federal agencies have either patched or submitted a deviation report.
The more interesting story is what happened in the gap between the advisory and the KEV listing. Two more companies disclosed. Both are small-to-mid. Both fit a pattern worth examining.
The SMB angle: why self-hosted BI keeps getting picked
Let me describe the environment you probably manage, because I have seen it at three different clients this year.
Finance wants a dashboard. The solution: spin up a $20/month cloud VM, install Metabase, point it at the production database, expose port 443, hand the URL to the accountant. Done. No ticket. No hardening. No patch management schedule. No one tells IT.
This is the attack surface. Self-hosted Metabase on a single cloud VM, default configuration, direct internet exposure, and credentials that connect to operational databases. When an unauthenticated SQL injection drops a Metabase admin session on an internet-facing host, you are not just losing your BI tool. You are losing your application database and every connected data source Metabase can reach.
This is why SMBs get hit first. Not because they are less important, but because the footprint is larger and less guarded. Enterprise organizations have WAFs, network segmentation, and change advisory boards. The SMB running Metabase on a DigitalOcean droplet has none of that.
The new victims: N8n, Kilo Code
N8n disclosed on 8 August 2026. The attacker obtained 136 customer records. Exposed data included names and email addresses, plus 5 bcrypt-hashed n8n Cloud passwords. No payment data. No workflow content. But passwords are passwords - even hashed ones get cracked, especially if the hashing configuration is suboptimal. If you have an n8n Cloud account registered with the same email address you use elsewhere, rotate it now.
Kilo Code reported a 4-hour incident window on 2 August 2026 affecting Kilo Slackbot. A small subset of users' Slack access tokens were exposed. Tokens have been invalidated server-side, which is the correct response. If you used Kilo Slackbot during that window, you should have received a notification. If you did not, check your connected applications list in Slack anyway.
Neither incident is massive by enterprise breach standards. But 136 customer records and Slack tokens are enough to run spear-phishing campaigns, pivot into connected services, or crack a weak bcrypt hash. The scale is small. The consequences are not.
Both disclosures land on the same timeline as the Framework, Tally, and LexisNexis incidents. The pattern suggests a coordinated reconnaissance sweep rather than targeted attacks on specific companies. That means if you were running a vulnerable version and your instance was public-facing, you were probably scanned.
By The Numbers
| Metric | Detail |
|---|---|
| CVE | CVE-2026-72898 |
| CVSS Score | 10.0 (Critical) |
| CWE | CWE-89 (SQL Injection) |
| Attack Vector | Unauthenticated, network-reachable |
| Affected Versions | Self-hosted 0.58 through 0.63; Metabase Cloud 1.58+ |
| Patched Minimum | 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5 |
| GHSA Published | 6 August 2026 |
| CISA KEV Added | 11 August 2026 |
| Federal Due Date | 14 August 2026 |
| N8n Records Exposed | 136 (names, emails, 5 bcrypt hashes) |
| Kilo Code Impact | Slack access tokens (4-hour window, 2 Aug) |
CISA KEV: what the federal catalogue actually signals
The KEV listing is not just a database entry. It is the United States government's formal statement that this vulnerability is being actively exploited in the wild. CISA BOD 26-04 requires federal agencies to remediate KEV-listed vulnerabilities within strict deadlines. That is a federal agency problem.
But here is the part that matters for ANZ SMBs: KEV status flows downstream through supply chain expectations. Your enterprise clients are running Third Party Risk Management programs. Your cyber insurance underwriter is monitoring CISA feeds. Your future SOC 2 audit will reference it. And for operators of critical infrastructure in Australia, the Security of Critical Infrastructure Act obligations mean you should have a process for tracking KEV additions that affect your environment.
The federal due date of 14 August has passed. If you are reading this after that date and you still have a vulnerable Metabase instance exposed to the internet, you are past the window. Prioritise accordingly.
The one-hour mitigation checklist
If you manage infrastructure for an SMB or MSP and you have not audited your Metabase exposure yet, here is a structured one-hour process.
Step 1 - Find every Metabase instance (15 minutes)
Query your cloud accounts for any running instances with port 3000 or 443 open that you did not provision deliberately. Check your DNS records for unusual subdomains. Ask your finance and operations teams directly: "Has anyone set up a dashboard tool in the last two years?" The answer will surprise you.
Step 2 - Check the version (5 minutes)
Open the Metabase instance, click the gear icon, go to Settings > About. Note the version number. If it starts with 0.58, 0.59, 0.60, 0.61, 0.62, or 0.63 and is below the patched minimum for that branch, you have a problem.
Step 3 - Check internet exposure (10 minutes)
Is port 3000 or 443 directly accessible from the public internet? Is there an AWS Security Group, Azure NSG, or firewall rule allowing 0.0.0.0/0 to that port? If yes, you were in scope for this attack. Move to Step 5 immediately.
Step 4 - Patch or isolate (15 minutes)
Upgrade to the minimum patched release for your branch. If you cannot patch right now - perhaps the instance is running a custom configuration you have not documented - block the /api/session/reset_password endpoint at the firewall. This stops the exploitation vector without requiring a full upgrade. It is a temporary measure only.
Step 5 - Check for indicators of compromise (10 minutes)
If you found an unpatched, internet-facing instance, assume it was scanned at minimum. Check your Metabase logs for POST requests to /api/session/reset_password that returned HTTP 400. Then check for subsequent GET requests to /api/user/current returning HTTP 200. If both appear in your logs, you have confirmation of exploitation.
Step 6 - Incident response if compromised (5 minutes + ongoing)
If you have indicators of compromise: revoke all Metabase sessions by deleting all rows from the core_session table. Review and rotate passwords for every database Metabase connects to. Audit your Metabase admin accounts and API keys. Pull query history and activity logs for the period around 2-6 August 2026. If Metabase connects to a data warehouse, review access logs there too.
FAQ
Q: Are Metabase Cloud customers affected? A: Metabase Cloud runs a managed version that has been patched. No customer action required. But check whether you have any self-hosted instances running alongside your cloud account.
Q: Does the attack require the Metabase API to be public?
A: No. The vulnerable endpoint is /api/session/reset_password, which is part of the standard web interface. Any internet-facing Metabase installation is potentially in scope.
Q: We found an unpatched Metabase instance but it was not internet-facing. Are we safe? A: Not necessarily. Was it ever internet-facing? Attackers may have gained access through another path. Check your internal network logs and assume reduced confidence in any credentials used by that instance.
Q: The CVSS score is 10.0. Is that warranted? A: Yes. An unauthenticated, network-reachable SQL injection that grants administrator access to the application database and can reach connected data sources is about as severe as it gets. There are no mitigating factors here.
Further Reading
- Original disclosure: Metabase SQL injection zero-day - check your instance now
- Named victims breakdown: real attacks, real companies
- August Patch Tuesday: ANZ SMB priorities
- Metabase Security Advisory (GHSA)
- Metabase vendor blog post on the incident
- The Hacker News coverage - 8 August 2026
- CISA KEV Catalog entry - CVE-2026-72898
- NVD Record
Mathew Clark / Founder, SecureInSeconds / Currently: trying to find the coffee mug I definitely left somewhere in this server room
