# The Tool You Use to See Your Data Is How Attackers Are Taking It


When your business intelligence platform becomes a pipeline for exfiltrating the very databases it's supposed to illuminate, something has gone structurally wrong — not just in the software, but in how organizations think about internal tooling risk.


Metabase, the open-source BI and analytics platform used by tens of thousands of companies to query and visualize their production databases, is under active exploitation. A SQL injection zero-day has been weaponized in targeted attacks aimed at customer data theft. Attackers aren't brute-forcing credentials or pivoting through perimeter infrastructure — they're walking in through the front door of a trusted internal tool and running their own queries against your database.


## Why Metabase Is a Particularly Dangerous Target


Most organizations think about attack surface in terms of what faces the internet. Metabase often sits in a grey zone: internal-facing enough that security teams don't treat it like an externally exposed application, yet connected directly to production databases containing customer PII, payment data, and business-critical records.


That connectivity is the point. Metabase's value proposition is that it can talk to everything — Postgres, MySQL, MongoDB, Redshift, BigQuery, Snowflake. A successful compromise doesn't just expose one database; depending on how the organization has configured its data connections, it can expose every datasource the platform has credentials for.


SQL injection in a tool whose core function *is* SQL feels almost absurd, but it reflects a deeper problem: analytics platforms are built to let users construct queries, which means the attack surface is inherently broad. The injection path in this zero-day reportedly requires no authentication in certain configurations — a pattern Metabase has seen before.


## This Is the Second Major Metabase Crisis in Two Years


In August 2023, CVE-2023-38646 dropped: a critical pre-authentication remote code execution flaw in Metabase Open Source and Metabase Cloud. Exploitation was trivial and went public within days of the disclosure. CISA added it to the Known Exploited Vulnerabilities catalog. Thousands of exposed instances were fingerprinted on Shodan. It was a bad few weeks for anyone running Metabase.


The current zero-day follows a familiar arc. The 2023 RCE vulnerability stemmed from how Metabase handled the setup token in its /api/setup/validate endpoint — a backend function that trusted user-supplied input in a context where trust was catastrophically misplaced. The pattern here isn't random; it's architectural. When a platform is built to flexibly execute database operations on behalf of users, the risk surface for injection and execution flaws scales with that flexibility.


What's different this time is the targeting. The 2023 exploitation was opportunistic and broad — mass scanning followed by cryptominer and reverse shell payloads. The current attacks appear more deliberate: customer data exfiltration suggests a threat actor with a commercial motive, mapping specific Metabase deployments to specific databases of interest before moving.


## The Configuration Problem Nobody Talks About


Even organizations that patch promptly remain exposed through a subtler issue: how Metabase database connections are provisioned. When someone sets up a Metabase data source, they enter credentials — typically a service account or, frequently, a connection string with admin-level privileges because it was easier to set up that way.


This is the quiet disaster underneath the zero-day headline. If attackers exploit the SQLi flaw and it runs in the context of an overprivileged database user — which is common — they're not just reading what Metabase can see. They may be able to read system tables, dump schema information, or in some database configurations, write data or execute commands.


The blast radius of a Metabase compromise depends almost entirely on how conservatively the underlying database connections were scoped. Most aren't conservative at all.


## What the Attack Chain Looks Like in Practice


Based on the pattern of exploitation, the likely attack flow runs something like this:


  • Initial access: Identify internet-facing or VPN-reachable Metabase instances via passive DNS, certificate transparency logs, or direct scanning
  • Exploitation: Submit crafted payloads through vulnerable API endpoints to achieve SQL injection without authentication
  • Enumeration: Use the injection to enumerate datasources, tables, and schema metadata
  • Exfiltration: Extract customer records, credentials, or business data through the same injection channel — often in batches to avoid rate-limiting or anomaly detection
  • Persistence (in more sophisticated cases): Attempt to use database-level access to create backdoor accounts or write files if the database user has sufficient privileges

    • Organizations with Metabase behind a VPN are not automatically safe. VPN compromise, insider threat, or lateral movement from another breach can all lead to Metabase without touching the perimeter.


    ## For Defenders: What to Do Right Now


    Patching is obvious and should happen immediately. But patching alone doesn't address the architectural exposure this incident has revealed.


    Immediate actions:

  • Audit all Metabase database connections and verify they use least-privilege service accounts
  • Review Metabase instance exposure — should it be reachable without VPN? Almost certainly not
  • Check database logs for anomalous query patterns from the Metabase service account over the past 90 days
  • If you're running Metabase Cloud, review Metabase's incident communications directly; cloud customers may have different exposure than self-hosted deployments

    • Structural changes worth making:

  • Rotate all Metabase database credentials as a precautionary measure — treat them as potentially compromised
  • Implement network-level egress controls on your database host to detect or block unexpected data transfers
  • Consider whether every analyst actually needs direct database access or whether curated models with row-level security can replace it

    • ---


    ## HackWire Analysis


    There's a pattern in how BI and analytics platforms get exploited that the broader industry still hasn't internalized. These tools are treated as productivity infrastructure — something IT provisioned for the data team — rather than as high-value attack targets sitting on top of the crown jewels.


    Metabase isn't alone here. Redash had its own serious vulnerabilities. Apache Superset has seen multiple injection and SSRF issues. Grafana's history includes auth bypass and path traversal. The common thread is that these platforms were built to maximize query flexibility and integration breadth, and security was bolted on as an afterthought.


    What makes this particular Metabase incident noteworthy is the data-theft specificity. The 2023 exploitation wave was messy and opportunistic — you could observe it happening in real time because ransomware affiliates and cryptominer operators aren't subtle. A targeted customer data theft campaign implies actors who did reconnaissance first. They knew what was on the other end of those database connections. That's a different threat model, and it suggests either that Metabase deployments are being mapped by commercial threat intelligence actors or that a specific industry vertical — fintech and healthcare are common Metabase users — is being systematically targeted.


    The deeper issue is that no patch fixes the governance problem. If your analysts have been running arbitrary SQL against production customer data through an internet-facing tool for the past two years, you have already absorbed the risk. The question is whether you're going to find out via a security audit or via a breach notification letter.


    For organizations running any BI platform: this is the moment to treat analytics infrastructure with the same security rigor as your API gateway. That conversation is overdue.


    — HackWire Editorial


    ---


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)