Introduction
On August 3, 2026, an attacker exploited a zero-day vulnerability in Metabase Cloud. The entry point: the password reset endpoint, targeted via SQL injection to escalate privileges all the way to administrator level. From that position, the attacker accessed the stored credentials for every database connected to the instance — and exfiltrated their contents. Three days later, Framework Computers disclosed that customer personal data — names, email addresses, phone numbers, and postal addresses — had been compromised. Metabase deployed an emergency patch to its cloud offering. Self-hosted instances, however, remain exposed until updated.
When Your BI Tool Holds the Keys to Your Data Warehouse
What stands out about this incident isn't the nature of the vulnerability itself — it's what it reveals about Metabase's actual role in modern data architectures. A BI platform isn't just a visualization layer: it centralizes connections to operational databases, the data warehouse, and sometimes test environments seeded with production data. It stores the credentials for all those connections. It uses them continuously to execute queries.
In this setup, compromising the analytics layer is enough to bypass every security control applied directly at the database level. The database wasn't the first target. The tool sitting above it was.
A Blind Spot in Your Access Reviews
Service accounts created for BI platforms tend to accumulate broad permissions — necessary for data teams to query sources freely. They often carry read access across entire schemas, and sometimes write access for specific use cases. Yet these accounts rarely go through the same review cycles as DBA accounts. Their credentials aren't systematically included in rotation policies. Their activity isn't always forwarded to the SIEM.
The Metabase incident puts a concrete face on that blind spot.
Immediate Actions for Self-Hosted Teams
All instances running version 58 or higher are affected. Metabase distinguishes two editions by the first digit of the version number: Community Edition (prefix 0.x) and Enterprise Edition (prefix 1.x), with patched branches available for both. The minimum safe versions currently available are:
- Branch 58: 0.58.24 / 1.58.24
- Branch 59: 0.59.21 / 1.59.21
- Branch 60: 0.60.17 / 1.60.17
- Branch 61: 0.61.11 / 1.61.11
- Branch 62: 0.62.9 / 1.62.9
- Branch 63: 0.63.5 / 1.63.5
If an immediate update isn't feasible, blocking the /api/session/reset_password endpoint at the reverse proxy level serves as a temporary mitigation. You should also revoke all active sessions, rotate credentials for every connected database, and audit activity logs for any signs of unauthorized access.
The Real Question: What Do Your Analytics Tools Actually Know About Your Databases?
Beyond the patch, this incident calls for a more fundamental audit. What access rights do your BI platforms actually hold over your data systems? Are those tools scoped to read-only access on strictly necessary tables, or could they potentially export entire schemas? Are the stored credentials within the perimeter of your secrets management policy? Are logs from these tools integrated into your monitoring stack?
Serious data governance doesn't stop at securing the databases themselves. It extends to every application layer that touches them — analytics tools, integration pipelines, internal APIs. Each represents an attack surface, and one that is typically far less monitored than the underlying systems.
Patching Metabase this week is necessary. Knowing precisely what all your analytics tools can do with your data is equally so.