On January 13, 2025, Metabase disclosed a zero-day vulnerability that allowed unauthenticated attackers to gain full administrative access to self-hosted instances. This flaw, with a CVSS score of 10.0, affected all versions from x.58.0 through x.63.2. Framework, a company using Metabase, confirmed that attackers accessed customer names, login IPs, addresses, phone numbers, and emails before they could patch.
Timeline
January 13, 2025: Metabase publicly disclosed the zero-day and released patches (versions x.63.3 and later). Cloud instances were already updated.
Before disclosure: Framework detected unauthorized access to their Metabase instance. The exact timeline between exploitation and detection isn't public, but the company reported customer data exposure in their breach notification.
Post-disclosure: Metabase published interim security measures for organizations unable to patch immediately, including restricting network access and implementing endpoint protection.
Which Controls Failed
Vulnerability management process: Framework's instance ran an unpatched version in the affected range. Whether they were on x.58.0 or x.63.2, they hadn't received the patch before attackers exploited the zero-day.
Network segmentation: The Metabase instance was accessible to unauthenticated users. If you're running a BI tool that connects to production databases, it shouldn't be internet-facing without additional authentication layers.
Anomalous access detection: An unauthenticated user gaining admin privileges should trigger alerts. Either Framework didn't have monitoring configured for privilege escalation, or the alerts didn't reach the right team fast enough.
Data access logging: While Framework detected the breach and identified what data was accessed, the detection came after exfiltration. Real-time monitoring of sensitive data queries might have shortened the window.
What Standards Require
PCI DSS v4.0.1 Requirement 6.3.1: "Security vulnerabilities are identified and addressed." You need a documented process for identifying vulnerabilities and assigning risk ratings. A CVSS 10.0 flaw demands immediate action.
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained." If Metabase connects to cardholder data, you need to track its version and patch status.
NIST CSF v2.0 Detect function (DE.CM-01): "Networks and network services are monitored to find potentially adverse events." Authentication bypass and privilege escalation are adverse events. Your SIEM or logging infrastructure should catch admin access from unexpected sources.
ISO/IEC 27001:2022 Control 8.8: "Management of technical vulnerabilities." The standard requires you to monitor vulnerability disclosures for software you use and apply patches based on risk. Zero-days with active exploitation move to the front of the queue.
SOC 2 Type II CC7.1: "The entity uses detection and monitoring procedures to identify anomalies." If your BI tool suddenly shows admin activity from an IP that's never authenticated before, that's an anomaly worth investigating.
Lessons and Action Items
Build a patch deployment pipeline for third-party software: You can't wait for your quarterly update cycle when a vendor releases a critical patch. Create a process that lets you test and deploy emergency patches within 24 hours. This means:
- Maintaining a staging environment that mirrors production
- Documenting rollback procedures
- Having pre-approved change windows for critical security updates
- Testing patches against your specific configuration
Segment BI tools from the internet: Metabase, Tableau, Looker, and similar platforms aggregate sensitive data from multiple sources. Put them behind a VPN or zero-trust access gateway. If you need external access for contractors or remote teams, require MFA and use IP allowlisting.
Monitor for privilege escalation: Configure alerts for:
- New admin accounts created
- Existing accounts granted admin privileges
- Admin actions from IPs outside your expected ranges
- Database queries accessing tables the user hasn't touched before
You don't need an enterprise SIEM. A script that parses Metabase's application logs and sends alerts when it sees admin activity from a new source IP would've helped Framework.
Inventory your data visualization tools: Walk through your BI platforms and document what data sources they connect to. If Metabase has read access to your customer database, treat it with the same security controls you'd apply to the database itself. This includes:
- Regular access reviews (who has admin rights?)
- Connection string audits (does it use a read-only database account?)
- Query logging (what data is actually being extracted?)
Test your incident response for SaaS and self-hosted tools: Framework had to notify customers about data exposure. Do you know which customer data lives in your BI tools? Can you query access logs to determine what an attacker viewed? Document the process before you need it.
Subscribe to vendor security advisories: Metabase publishes security updates through their blog and GitHub releases. Add those feeds to your security team's monitoring. When you see a CVSS 10.0 disclosure, you need to know within the hour, not when someone mentions it in Slack three days later.
Consider managed services for critical infrastructure: Metabase Cloud instances were patched before the public disclosure. If you're running a small security team and can't commit to 24-hour patch cycles, paying for managed hosting might be cheaper than dealing with a breach. Calculate the cost of your team's time to maintain, monitor, and patch a self-hosted instance versus the SaaS premium.
Zero-days happen. The difference between a close call and a breach notification comes down to how quickly you can patch, how well you've segmented access, and whether your monitoring catches the exploitation before data walks out the door.
