AI uncovers 38 vulnerabilities in largest open source medical record software

AISLE Discovers 38 CVEs in Healthcare Software Used by 100,000 Medical Providers

Healthcare is digitizing faster than it is being secured. AI-assisted diagnostics, telemedicine, and automated billing are expanding access to care at unprecedented speed, but the security practices protecting these systems have not kept up. At the same time, attackers are increasingly using AI to find vulnerabilities faster than ever. The result is a widening gap between what healthcare software can do and how well it is defended.

OpenEMR sits squarely in that gap. It is one of the most widely adopted open-source electronic health record platforms in the world, used by over 100,000 medical providers serving more than 200 million patients across 34 languages. OpenEMR 8.0, released in February 2026, is ONC-certified under the U.S. federal Health IT certification program, including the full set of Privacy and Security criteria (§ 170.315(d)(1) through (d)(13)). Such reach makes protecting it essential.

That is why we chose OpenEMR as a focus of our open-source partnership security work. Our goal is to strengthen critical infrastructure by applying the same autonomous analysis engine that uncovered twelve zero-days in OpenSSL to a codebase that millions of patients depend on daily. The OpenEMR maintainers collaborated closely with us and responded to findings with speed and professionalism. What follows is a summary of what we found, how the issues were fixed, and what this experience reveals about the state of healthcare application security.

The Findings at a Glance

During Q1 2026, AISLE researchers Stanislav Fort, Petr Simecek, and Pavel Kohout applied the AISLE AI analyzer to the OpenEMR codebase and discovered 38 CVEs, accounting for more than half of all OpenEMR security advisories published on GitHub during this period.

For comparison, the most prominent prior independent security audit of OpenEMR was the 2018 Project Insecurity report, which generated international press coverage and disclosed 23 vulnerabilities after an extended research effort by a dedicated human team. AISLE's analyzer found 38 in just one quarter.

These vulnerabilities could have enabled a broad range of attacks against OpenEMR deployments. In the most severe cases, SQL injection vulnerabilities combined with modest database privileges could have led to full database compromise, PHI exfiltration at scale, and remote code execution on the server.

Notable Findings

Each of these vulnerabilities could be exploited to access or rewrite sensitive patient data:

CVE-2026-24908: SQL Injection in Patient REST API Sort Parameter

The second CVSS 10.0 finding lived in OpenEMR's Patient REST API, where the _sort query parameter lets clients choose the ordering for returned results. The values passed to _sort were concatenated directly into SQL ORDER BY clauses with no validation. A single missed call meant any authenticated client with an OAuth2 bearer token could exploit the flaw to extract credential hashes, perform time-based blind injection, or escalate to remote code execution if the database user held FILE privileges.

CVE-2026-23627: SQL Injection in Immunization Search/Report

The Immunization module's search and report endpoints had a similar flaw. The patient_id form parameter was stitched directly into SQL WHERE clauses without parameterization. A UNION SELECT could extract data from any table in a single request, and if the database user held FILE privileges, the attacker could also read server files or write a web shell.

CVE-2026-24487: FHIR Patient Compartment Bypass in CareTeam

The FHIR CareTeam endpoint returned care team data for every patient in the system, even when the request carried a patient-scoped OAuth2 token. The root cause was architectural: OpenEMR's FHIR layer uses a PHP interface as a marker to decide which services receive patient-scoping filters. The FhirCareTeamService class never declared that interface, so no patient filter was injected.

Autonomous Issue Fixes

For each of the 38 CVEs, AISLE generated a repository-native fix proposal that reused OpenEMR's own abstractions. This significantly reduced the time to remediation and made it easier for OpenEMR's dedicated maintainers to secure the codebase.

A Partnership for Patient Safety

Our engagement with OpenEMR began in mid-December 2025. The bulk of the AISLE-reported fixes shipped in OpenEMR 8.0.0 on February 11, 2026. In early April 2026, we formalized the partnership by integrating AISLE PRO into OpenEMR's code review workflow to detect vulnerabilities before they enter production.

"For a project like OpenEMR, where the stakes are patient safety and health data privacy, we couldn't be more excited about our partnership with AISLE. Their autonomous analyzer uncovered dozens of vulnerabilities in our codebase. Now, we're catching and fixing vulnerabilities before they ever reach production."

— Brady Miller, MD, Executive Director of the OpenEMR Foundation

From Disclosure to Prevention with AISLE

AI-powered attacks increasingly target healthcare institutions. Defenders need matching coverage. The OpenEMR engagement is what that looks like in practice: an autonomous analyzer finding real vulnerabilities in critical software and moving upstream to catch new vulnerabilities at code review.