38 OpenEMR Flaws Found by AI and What Practices Should Patch

OpenEMR is a free, open-source electronic health records and practice management system. Practices that want to avoid commercial EHR licensing fees often run it on their own servers or through a hosting partner. In early 2026, a security firm using an AI code analyzer reported 38 vulnerabilities in it, including flaws that could expose an entire patient database.

The good news is that all of them were fixed in releases shipped between February and March 2026. The risk sits with any practice still running an older version. Here is what was found, which versions are affected, and how the findings connect to the HIPAA Security Rule.

Who found the flaws and how

The research came from AISLE, an AI-based application security company. According to its April 28, 2026 write-up, researchers Stanislav Fort, Petr Simecek and Pavel Kohout ran the AISLE AI analyzer against the OpenEMR codebase starting in mid-December 2025. They reported the first findings to OpenEMR's maintainers in mid-January 2026 and disclosed responsibly, meaning the details were kept private until fixes were available.

AISLE also proposed code fixes that fit OpenEMR's existing authorization and sanitization patterns. For some of the critical issues, the maintainers adopted those proposals into the final patch. The HIPAA Journal reported that the work produced 39 GitHub security advisories, 38 of which received CVE identifiers. AISLE says that was more than half of all OpenEMR security advisories published on GitHub in the first quarter of 2026.

By AISLE's breakdown, the 38 CVEs include:

• 3 critical, 15 high and 20 medium severity issues.
• 24 authorization flaws, where a logged-in user could reach data or functions their role should not allow.
• 9 cross-site scripting (XSS) flaws, where malicious script could run in another user's browser.
• 5 others, covering SQL injection, path traversal and a session issue.

The three critical flaws

The OpenEMR security advisories on GitHub rate three of the AISLE findings as critical. All three affect versions before 8.0.0 and are fixed in 8.0.0.

The National Vulnerability Database entries describe the consequences in plain terms: database access, exposure of protected health information, and stolen credentials. For the immunization flaw, NVD adds the potential for remote code execution. The MedEx flaw is the most serious because it required no login at all, so any OpenEMR server reachable from the internet was exposed. NVD's own scores differ from GitHub's on some of these (for example, NVD scored CVE-2026-24908 lower), which is common, but all three are serious for a system holding patient records.

Affected versions and the fix

This is the part the original coverage left out:

• Version 8.0.0, released February 11, 2026, fixed the three critical flaws and most of the others.
• Versions 8.0.0.1, 8.0.0.2 and 8.0.0.3, released through March 2026, fixed the rest. Version 8.0.0.3 was published on OpenEMR's GitHub on March 25, 2026.
• Affected: any install older than 8.0.0 is exposed to the critical issues. Some of the later fixes cover versions up to 8.0.0.2.

In short, 8.0.0.3 is the minimum version that includes every AISLE fix. But it should not be the target. OpenEMR has kept shipping releases (8.5.0 came out on October 27, 2026), and it has published well over 100 more security advisories since mid-August 2026. The practical goal is a current, supported release, plus a process for applying new security releases as they come out.

Why this matters under HIPAA

A practice that bills insurance electronically is usually a HIPAA covered entity, and its EHR is the main store of electronic protected health information (ePHI). Known, unpatched vulnerabilities in that system touch several parts of the HIPAA Security Rule:

• Risk analysis and risk management (45 CFR 164.308(a)(1)(ii)(A) and (B)). The rule requires an accurate assessment of risks to ePHI and measures to reduce them to a reasonable level. A publicly disclosed critical flaw in your EHR is a known risk.
• Information system activity review (164.308(a)(1)(ii)(D)). Logs and access reports need regular review, which matters if a flaw may already have been exploited.
• Access control (164.312(a)(1)). The 24 authorization flaws are exactly the kind of gap this standard targets: users reaching records their role shouldn't allow.
• Audit controls (164.312(b)). Logging has to be on and kept so you can tell what happened.
• Integrity (164.312(c)(1)). SQL injection can alter or destroy records, not just read them.

If a review shows the flaws were exploited, the Breach Notification Rule may apply. Notice to affected patients is due without unreasonable delay and no later than 60 days after discovery, with HHS and media notice depending on how many people are affected. Talk to counsel early if logs show suspicious activity.

A practical checklist for OpenEMR users

These are steps practices running OpenEMR commonly take. Your risk analysis should set priorities.

Find out where you stand

• Confirm the exact OpenEMR version on every server, including test, training and backup copies.
• Ask your hosting provider or IT vendor which version they run for you and when they patch.
• Check whether the OpenEMR login page, patient portal or API is reachable from the public internet.

Patch

• Upgrade to a current supported release, not just 8.0.0.3.
• Test on a copy first if you have custom forms or integrations, but don't let testing delay a critical fix for months.
• Subscribe to OpenEMR's GitHub security advisories so new fixes don't go unnoticed.

Reduce exposure

• Put the system behind a VPN or restrict access by IP address where you can.
• Disable modules and APIs you don't use. If you don't use MedEx, make sure its endpoints aren't reachable.
• Run the database account with the least privileges needed. AISLE notes that two of the SQL injection flaws could escalate to file access and server takeover when the database user had file privileges.
• Review user roles and remove accounts for people who have left.

Look back

• Review web server, API and database logs from before you patched for signs of unusual queries or access.
• Rotate API tokens and passwords, especially MedEx tokens and any API client credentials.
• Record what you found and what you changed in your risk analysis documentation.

Vendors

• If a third party hosts or supports your OpenEMR, check that a business associate agreement is in place and that it covers patching and incident notice.

Where NutriCove fits

NutriCove builds AI automation for medical offices, such as an AI receptionist, missed-call text back, follow-ups and booking. We don't patch or host EHR systems. Any automation that connects to patient records adds another system holding PHI, which is why our medical page notes that GoHighLevel needs its HIPAA add-on and a signed BAA before any PHI goes in. If you're weighing patient-facing automation, see how we set it up for medical offices.

Sources

• AISLE Discovers 38 CVEs in Healthcare Software Used by 100,000 Medical Providers, AISLE
• AI Analysis Identifies 38 Flaws in OpenEMR Platform, HIPAA Journal
• OpenEMR security advisories, GitHub
• Unauthenticated MedEx Session-Token Disclosure via Callback Endpoint (GHSA-qwff-3mw7-7rc7), OpenEMR on GitHub
• SQL Injection in Patient API Sort Parameter (GHSA-rcc2-45v3-qmqm), OpenEMR on GitHub
• SQL Injection in Immunization Search/Report (GHSA-x3hw-rwrg-v25h), OpenEMR on GitHub
• CVE-2026-24898, National Vulnerability Database
• OpenEMR releases, GitHub
• 45 CFR Part 164 Subpart C, Security Standards, eCFR
• Breach Notification Rule, HHS

This article is general information, not legal or medical advice. Talk to a qualified attorney or licensed professional about your situation.