The tool you forgot to list on the security questionnaire. A critical Metabase flaw let attackers into patient data at HealthTech companies through their analytics tool. A BI tool that reads production data sits inside your PHI boundary, and it belongs on your inventory and your questionnaire answers. 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. * 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. * 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. * 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. * Narrow the connections. Point analytics at a replica or a de-identified dataset where you can, and give each tool its own scoped credential. * Put these tools in the patch process with an owner and a deadline, the same as the product. * 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.

Blueberry Pediatrics reports multiple data breach linked to Metabase vulnerability. Blueberry Pediatrics has reported a data security incident it suffered earlier this year that compromised the sensitive personal information of over 64,000 individuals. Blueberry Pediatrics (Blueberry Medical) is a tele health service connecting parents with board-certified pediatricians through an app. Members receive a home medical kit for remote assessments, diagnoses, and prescriptions. The company uses Metabase, an open-source BI platform, for internal data analytics, SQL queries, and interactive dashboards. In August, threat actors exploited a critical vulnerability in Metabase to gain unauthorised administrative access to vulnerable environments. The flaw exposed sensitive data to potential unauthorised access, highlighting the importance of timely security patches and proper access controls. In a data security incident notice, Blueberry Pediatrics said that on August 22, the tele healthcare provider identified unauthorised activity to its Metabase environment. The healthcare provider said it promptly initiated an investigation, engaging external cybersecurity experts to assess the nature and scope of the incident. The investigation determined that the threat actor who exploited the Metabase vulnerability copied some of Blueberry Medical patient data. On August 24, 2026, Blueberry Medical was informed that Photon, its prescription service provider, also suffered a separate cyber incident involving a different attacker exploiting the same Metabase vulnerability. The incident exposed a copy of some of the same information affected by Blueberry Medical's incident. The compromised data included names, health plan names and policy numbers, dates of birth, and health care information and more. Other information affected during the Photon incident also included names, street addresses, phone numbers, email addresses, or member IDs and medication information. Blueberry Medical reported the incident to the Texas Attorney General's Office where it said at least 67,830 individuals were affected by the incident. The tele healthcare provider added that clinical photos and medically necessary videos used for diagnosis are stored separately and remain secure, with no compromise. Furthermore, the exposed information did not include Social Security numbers or payment details. "To prevent future occurrences and in light of the Metabase incident, Blueberry Medical has strengthened its authentication, implemented an additional monitoring and escalation process for its vendors' critical vulnerabilities, and increased the frequency of security reviews for third-party and self-hosted technology infrastructure, such as Metabase," Blueberry Medical said. It has urged affected individuals to closely monitor their credit reports, account and benefit statements for any suspicious activity and to report potential identity theft or fraud to law enforcement, including local police and the state attorney general.