What Happened
Metabase disclosed a SQL injection vulnerability (CVE-2025-0005) with a CVSS score of 10.0 that was exploited before patches were available. The vulnerability affects Metabase versions 1.58 and above. Attackers used the flaw to extract customer data from at least two confirmed victims: Framework and Tally, both running self-hosted Metabase instances for business intelligence and analytics.
The exploit allowed unauthenticated attackers to execute arbitrary SQL queries against the underlying database, bypassing all application-layer access controls. Metabase confirmed active exploitation and released emergency patches for affected versions.
Timeline
Pre-disclosure: Attackers identified and exploited the SQL injection flaw in production environments.
Disclosure: Metabase published security advisories and released patches for all affected versions (1.58+).
Post-disclosure: Framework and Tally confirmed data breaches. Both organizations notified affected customers and began incident response procedures.
Current state: Metabase has urged all self-hosted customers to upgrade immediately. Cloud-hosted instances were patched by Metabase directly.
Which Controls Failed or Were Missing
Input Validation
The SQL injection vulnerability highlights a failure in input validation and parameterized query usage. User-supplied input reached a SQL query without proper sanitization or prepared statements.
Vulnerability Scanning
Organizations running self-hosted Metabase instances lacked real-time detection of the vulnerability before exploitation. Static and dynamic application security testing (SAST/DAST) should identify SQL injection patterns, but these controls are only effective if you're running them against your BI tools, not just your custom code.
Patch Management
The gap between vulnerability disclosure and patch deployment created the exploitation window. Self-hosted environments require manual intervention to deploy updates, unlike cloud-hosted instances that Metabase can patch centrally.
Network Segmentation
If your Metabase instance can directly query production databases without network-layer restrictions, an SQL injection vulnerability becomes a direct path to your most sensitive data. Framework and Tally's breach scope suggests their BI tools had broad database access.
Monitoring and Detection
Neither organization detected the unauthorized SQL queries in real-time. Database activity monitoring should flag unusual query patterns, especially from application service accounts executing queries that don't match normal BI workload characteristics.
What the Relevant Standards Require
PCI DSS v4.0.1
Requirement 6.2.2: Review and assess vendor-supplied security patches and install applicable critical patches within one month of release.
For zero-day scenarios, this requirement doesn't help before disclosure. But it mandates a process for rapid patch deployment once vendors release fixes. If you're still running unpatched Metabase instances weeks after the advisory, you're non-compliant.
Requirement 6.4.3: Protect web applications from common attacks, including injection attacks.
This applies whether you built the application or bought it. If you're running self-hosted Metabase, you're responsible for protecting it against OWASP Top 10 vulnerabilities, including SQL injection.
OWASP ASVS v4.0.3
Requirement 5.3.4: The application protects against SQL injection attacks by using parameterized queries, ORMs, or database stored procedures.
This is the control that failed in Metabase's code. But for security engineers running third-party applications, ASVS 14.2.1 is more relevant: verify that all components are up to date and that security patches are applied in a timely manner.
ISO/IEC 27001:2022
Control 8.8: Management of technical vulnerabilities requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures.
This means you need a process to learn about Metabase security advisories the day they're published, not three weeks later when an auditor asks about your patch status.
Lessons and Action Items for Your Team
Treat BI Tools Like Production Applications
Your Metabase, Tableau, or Looker instance has the same access to customer data as your production API. Apply the same security controls:
- Include third-party applications in your vulnerability scanning schedule
- Monitor database queries from BI service accounts for anomalies
- Segment BI tool database access using read-only replicas or views when possible
Build a 24-Hour Patch Window for Critical Vendors
You can't patch what you don't know about. Create a vendor watch list and monitor security advisories:
- Subscribe to Metabase's security mailing list and GitHub security advisories
- Set up automated alerts for CVE publications mentioning your critical vendors
- Document your patch deployment process so you're not improvising during a zero-day
For self-hosted applications rated Critical (CVSS 9.0+), aim to deploy patches within 24 hours of availability. Test in staging, but don't let perfect be the enemy of fast.
Separate Self-Hosted and Cloud Risk Models
Framework and Tally got breached because they run self-hosted Metabase. Cloud customers were patched automatically. This isn't an argument for or against self-hosting, but it does mean your security responsibilities differ:
Self-hosted: You own patch management, network segmentation, and infrastructure hardening. Budget time for security updates.
Cloud-hosted: You depend on the vendor's patch velocity and incident response. Verify their SLAs for security updates and ask about their detection capabilities.
Implement Database Activity Monitoring
If an attacker executes SELECT * FROM customers WHERE 1=1-- through your BI tool, your database should notice. Deploy monitoring that baselines normal query patterns and alerts on:
- Queries from application accounts that return unusually large result sets
- SQL comments or syntax patterns associated with injection attacks
- Access to tables that the service account rarely queries
Don't wait for your SIEM to correlate application logs. Monitor at the database layer where the actual data exfiltration occurs.
Test Your Incident Response for Third-Party Breaches
When Metabase disclosed the vulnerability, how long did it take your team to:
- Confirm which versions you're running
- Check logs for signs of exploitation
- Deploy the patch to production
- Notify affected stakeholders
If you don't have documented answers, run a tabletop exercise. The next zero-day won't wait for you to figure out your process.
