Metabase SQL Injection Zero-Day Exploited — Framework and Tally Confirm Breaches

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Application security, cloud infrastructure and platform hardening for US and EU products

The short answer

What happened

Metabase detected intrusions on August 3, 2026. Three days later, on August 6, the company notified affected customers, blocked the API endpoints used in the attacks, and shipped patched releases. Public disclosure followed on August 7.

Framework was the first major victim to go public. In an email to all customers sent August 7, the company said attackers accessed customer records through a third-party service — Metabase — it uses for business intelligence. The stolen data included names, email addresses, phone numbers, and both billing and shipping addresses. Payment information was not part of the breach.

Tally, which builds digital forms used by thousands of businesses, confirmed a separate compromise that exposed email addresses and hashed passwords for its user accounts, though customer form data was not reached. LexisNexis also disclosed that its Metabase API integration was hit; the scope of that exposure has not been confirmed.

How the vulnerability works

The flaw is an unauthenticated SQL injection in the Metabase application layer. Metabase stores connection strings, credentials, and query results for every data source it manages. By injecting SQL directly into the Metabase database — without needing to authenticate first — an attacker can elevate to administrator, read stored database credentials, and from there pivot into every data source the Metabase instance connects to.

The potential blast radius is large. Metabase instances in production environments often hold database credentials for multiple data warehouses, transactional databases, and external APIs. Compromising Metabase can therefore expose far more than the analytics data visible in dashboards. For teams where Metabase queries production databases directly, the entire dataset is in scope. This is exactly why regular security audits should include BI and analytics tooling, not just application servers and APIs.

No CVE number has been assigned yet. The CVSS score is 10.0 — the maximum possible — reflecting the combination of no authentication required, full data exposure, and remote exploitability.

How to detect a compromise

Metabase identified a specific log signature associated with the attack: a POST request to /api/session/reset_password returning HTTP 400, followed immediately by a successful GET request to /api/user/current returning HTTP 200. Check your web server and application logs for this pattern. If you find it, the instance should be treated as fully compromised.

The remediation path from a confirmed compromise: rotate every database credential and API key stored in or accessible via Metabase, audit which datasets and downstream systems the instance had access to, and review access logs on those systems for unusual query patterns or data exports during the window between August 3 and August 6.

What it means for US & EU software teams

The Metabase breach follows a pattern seen repeatedly in 2026: the weakest security link in a software stack is often not the custom application but the third-party operational tooling that sits around it. Metabase is positioned as an internal analytics tool, which tends to get less security scrutiny than customer-facing systems — even though it holds access credentials to the same databases those systems query.

For FinTech, HealthTech, and E-commerce teams, this matters acutely. Metabase instances in these environments often connect to databases containing financial records, PII, health data, or payment history. Under GDPR, a breach involving EU resident data must be reported to the relevant data protection authority within 72 hours of awareness. Under HIPAA, health data breaches trigger notification requirements to the Department of Health and Human Services and potentially to affected individuals.

The broader architectural lesson is about blast radius. A tool that aggregates credentials across multiple data sources becomes a high-value target. Treat your analytics and BI layer with the same access controls, patch discipline, and audit coverage you apply to your API layer.

What to do now

• Identify your version. In Metabase: Settings → Admin → Troubleshooting → Version. Match it to the affected range (any 1.58–0.63 release).
• Patch immediately. Upgrade to the fixed release for your minor version: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, or 0.63.5. If you run Metabase Cloud, the fix was applied automatically; verify by checking the version shown in your instance.
• If you cannot patch right now, take the instance offline or block external access until you can. An unpatched, internet-accessible Metabase instance is an active liability.
• Check your logs for the attack signature described above. If you find it, begin incident response: rotate credentials, audit downstream systems.
• Rotate stored credentials proactively, regardless of log evidence. The attack was running for at least three days before detection. If there is no log evidence of compromise, rotating credentials is still the right precaution.
• Review Metabase’s network exposure. BI tools in most environments should not be directly internet-accessible. If yours is, restrict it to VPN or internal network access only.
• For EU teams under GDPR: if your Metabase instance held EU resident personal data and you find evidence of access, the 72-hour notification clock to your DPA may have started on August 3.

Frequently asked questions