VULNpocalypse
HighVulnerabilityPatch available

IDNSEC reports 42 OpenEMR advisories fixed in 8.5.0, patch now

IDNSEC reports 42 OpenEMR advisories credited to its research, fixed in 8.5.0; self-hosted operators should upgrade to 8.5.0.

Published
Fixed in
OpenEMR 8.5.0
Exploitation
No, the sources report no exploitation in the wild (not confirmed either way)

What happened

According to a research write-up by Fariskhi Vidyan on IDNSEC, an AI-assisted security review of OpenEMR, an open source electronic health record platform, found local file disclosure, SQL injection, access control flaws and other issues. IDNSEC says OpenEMR 8.5.0, released on 27 October 2026, fixes 84 security advisories, and that 42 of them credit this research (30 original reports and 12 additional finder credits). The author says the work was done in September 2026 with GPT-5.6-sol and tested on OpenEMR 8.4.1.

IDNSEC gives this severity split for the 42 advisories: 3 critical, 15 high and 24 medium. It says more findings remain unpublished while fixes are in progress, so the full count of accepted reports is not confirmed. It also says CVE IDs are still pending, so it uses GHSA IDs. None of the sources provide a CVE ID.

Four of the advisories were published by the OpenEMR project on GitHub on 28 October 2026. Each lists affected versions as below 8.5.0 and the patched version as 8.5.0:

  • GHSA-h4xc-pqg3-8459, rated Critical. An authenticated patient or core user can make the server read local files through the mPDF PDF renderer, via user-controlled HTML sent to /portal/lib/doc_lib.php. The advisory says remote code execution is not reachable in OpenEMR here, because it needs a PHP version that OpenEMR does not support. IDNSEC says it reported the mPDF behavior to mPDF, and that no hardening was added because HTML input for PDF conversion is not expected to come from external sources.
  • GHSA-wh28-4qcg-5hcc, rated Critical, CVSS 9.3. Any authenticated core user can inject SQL through the CCR approval controller. The advisory says this can expose database contents and alter any patient’s demographics.
  • GHSA-83hq-c876-fcwf, rated High, CVSS 8.6. A low-privilege core user can replace another patient’s portal credentials, and the advisory says this requires the patient portal to be enabled. Based on commit-history analysis, it lists affected versions as v4.1.0 through v8.4.1.
  • GHSA-79g8-hm7q-xrh4, rated High, CVSS 7.1. The dynamic patient finder returns patient demographic data, including Social Security numbers, to any authenticated core user, even without the patients/demo permission. Based on commit-history analysis, it lists affected versions as v4.1.1 through v8.4.1.

IDNSEC’s TLDR also mentions an administrator API impersonation chain. The source text provided does not include its details, so they are not confirmed here. No source reports that any of these issues was exploited against a real deployment.

Am I affected?

According to the four GitHub advisories, OpenEMR versions below 8.5.0 are affected. The author tested on 8.4.1.

  • Every issue in the four advisories above requires an authenticated session, either a core (staff) account or, for the PDF issue, a patient portal account.
  • The portal credential issue applies only where the patient portal is enabled.
  • Whether other versions or the other 38 credited advisories behave differently is not confirmed in the sources provided.

What to do now

  1. Upgrade OpenEMR to 8.5.0, the patched version named in the GitHub advisories.
  2. Read the project’s published advisories for the 8.5.0 release. IDNSEC says 84 advisories were fixed and more findings are unpublished, so details may still be added.
  3. Check who holds core (staff) accounts on your instance. Several of these issues are reachable by any authenticated core user, including one with no patient permissions. This is our suggestion, not an instruction from the sources.
  4. If you cannot upgrade immediately, there is no workaround in the sources provided. Mitigations are not confirmed.

Sources