Metabase CISA KEV Alert: Patch CVE-2026-72898 Now
August 11, 2026
CISA added Metabase CVE-2026-72898 to its Known Exploited Vulnerabilities catalog on August 11, 2026. Metabase rates the issue Critical and confirms active attacks against vulnerable self-hosted installations. Treat this as an emergency application-maintenance change: move to the fixed release for your supported branch, validate normal service, then review access and connected database protection.
Who needs to act
This guide is for teams that run Metabase themselves, whether it sits on a server, virtual machine, container platform, or hosting environment. The vendor advisory lists the following vulnerable and fixed releases:
| Release branch | Vulnerable through | Fixed release |
|---|---|---|
| x.58 | x.58.23 | x.58.24 |
| x.59 | x.59.20 | x.59.21 |
| x.60 | x.60.16 | x.60.17 |
| x.61 | x.61.10 | x.61.11 |
| x.62 | x.62.8 | x.62.9 |
| x.63 | x.63.3 | x.63.5 |
Record the installed version from your normal administration or deployment inventory before making the change. For a managed service, confirm who owns the upgrade responsibility and obtain the provider’s current status in writing.
Make the update an emergency, controlled change
- Assign a change owner, customer-impact contact, and an explicit recovery decision point.
- Use the existing documented recovery plan for this service. Do not create an untested archive in the middle of an urgent response.
- Apply the vendor-supported fixed release for the branch you run, or move to a supported newer branch after confirming compatibility.
- Keep public administration exposure as limited as your normal access policy allows while the update is in progress. If the change cannot begin promptly, follow the vendor’s current temporary-mitigation guidance through the established access-control process.
- Confirm the service returns normally, that approved administrators can sign in, and that a small representative set of dashboards and scheduled work behaves as expected.
Review access and data connections after patching
A successful version change does not establish whether a system was touched before the fix. Use the incident-response process appropriate for your organization to review unexpected administrator changes, access keys, user sessions, connection settings, and data-access history. Where the review indicates possible exposure, rotate relevant connected-database credentials and involve your security owner or incident-response provider.
Keep the hosting layer in scope
Metabase commonly runs alongside reverse proxies, containers, virtual machines, and database services. Patch the application first, then schedule any separate operating-system, platform, or dependency maintenance under the normal change process. Do not turn a focused emergency patch into a broad production rebuild without a tested plan.
Operational checklist
- Identify every self-hosted Metabase installation and its installed release.
- Move each affected installation to the vendor-fixed release for its branch.
- Validate normal administrator access, dashboards, scheduled work, and monitoring.
- Review privileged access and connected-data protection for signs that need escalation.
- Communicate the maintenance window and follow-up status to affected users or customers.
Keep site support disciplined too
Teams that operate analytics and hosting systems often manage WordPress sites as well. Our WordPress support guides cover the same practical habits: controlled updates, clear ownership, post-change checks, and a recovery decision before a maintenance window begins.
