The tool you forgot to list on the security questionnaire

A business intelligence tool connected to a production database can read whatever that connection can read. Metabase's own advisory for its critical SQL injection flaw says an unauthenticated attacker who gained admin access could steal stored credentials for the connected databases, read any data accessible through those connections, and export data. Metabase confirmed active exploitation and published patched versions on Aug. 6, 2026.

Two HealthTech companies have since said in their own words what that meant for patient data.

Dorsata said in its Oct. 14 notice that the Metabase vulnerability allowed unauthorized access to its database platform storing medical information for patients of its healthcare provider partners between Aug. 10 and Aug. 12, 2026. The information that may have been involved included names, addresses, dates of birth, vitals, treatment information, medications, vaccines, health insurance information, and medical history. Dorsata said there was no evidence of misuse and that Social Security numbers and financial information were not involved.

Blueberry, a pediatric telehealth service, disclosed that an attacker exploited a Metabase vulnerability to copy patient data. According to CyberInsider's report on Blueberry's notification, Blueberry used the platform for reporting and data analysis, discovered the access on Aug. 22, and a separate public statement placed the initial intrusion on Aug. 10. The potentially exposed data included names, dates of birth, health plan details, medical records, dates of service, and medical codes. Blueberry said Social Security numbers and payment information were not involved, and that clinical photos and videos were stored separately and not compromised.

I am not going to describe how the flaw works. The lesson for founders sits somewhere else entirely.

The BI tool is inside the boundary

When a HealthTech company draws its PHI boundary for a security questionnaire, it usually lists the application, the database, the cloud provider, and the EHR integration. The analytics tool often goes unmentioned. It feels internal. It is used by the ops team and the founders to look at dashboards. It is not "the product."

But a BI tool with a live connection to production holds credentials to that database, can run queries against it, and can export results. By the plain reading of Metabase's own advisory, an attacker who took over the BI tool could reach everything the tool could reach. If the tool can read PHI, it is inside the PHI boundary, whether or not it shows up on your architecture diagram.

The same is true for the rest of the category: notebooks, desktop SQL tools with saved connections, reverse ETL tools, data warehouse sync jobs, and increasingly, AI assistants that have been given a database connection so someone can "ask the data a question."

Why it gets missed

A few patterns show up again and again.

It was set up by one person. An early engineer or a data-curious founder stood up the BI tool in an afternoon, often self-hosted, often with an admin account and a read connection to the primary database.

It sits outside the patch process. The product gets deployed through CI. The BI tool gets updated when someone remembers. Metabase's advisory lists six affected version ranges, and a self-hosted instance only gets patched if someone owns that job.

It is reachable from the internet. Dashboards get shared, people work from home, and a login page ends up public. Metabase's remediation guidance specifically addresses instances where a sensitive endpoint was publicly accessible.

It is not on the vendor list. Questionnaires ask for subprocessors and systems that store or process PHI. A self-hosted analytics tool is not a vendor in the usual sense, so it falls through both lists.

An inventory of tools that read production

Here is the defensive checklist I would run this week.

1. List every tool with a credential to a production database or data warehouse. Start from the database side: list every user, role, and service account, and trace each one to the tool or person that uses it.
2. For each tool, record who owns it, how it is hosted, what version it runs, and whether its login page is reachable from the internet.
3. Record what each connection can read. If a dashboard tool has a read connection to tables with PHI, mark it as in scope for PHI.
4. Narrow the connections. Point analytics at a replica or a de-identified dataset where you can, and give each tool its own scoped credential.
5. Put these tools in the patch process with an owner and a deadline, the same as the product.
6. Add them to your security questionnaire answers and your architecture diagram.

If you use Metabase specifically, follow the vendor's remediation steps, which include upgrading, revoking sessions, reviewing API keys and admin accounts, rotating connected database credentials, and reviewing query history.

The AI version of this problem

The next tool you forget to list will probably be an AI one. Teams are connecting AI assistants and agents to databases so anyone can ask questions in plain language. That assistant holds a credential, runs queries, and returns data, exactly like the BI tool did. It belongs on the same inventory with the same questions: who owns it, what can it read, where is it hosted, and is it on the questionnaire.

For leadership, this is an AI readiness question. Before a company adds AI features that touch production data, it should be able to list every existing tool that already does.

Start from the database

Pull the list of every account that can read your production database or warehouse, and put a tool name and an owner next to each one. Any account you cannot explain is the first thing to look at, and any tool on that list that is not in your questionnaire answers is the second.