OpenEMR advisories cover portal, fax and FHIR flaws

OpenEMR is open-source electronic health record software, and three of its recent GitHub security advisories describe the same underlying pattern: access checks that exist in one code path and are missing in its sibling. None of the advisories reports exploitation in the wild.

What the advisories say

Fax/SMS module, rated critical. Per the maintainer advisory, published Aug 18, 2026, two vendor clients in the bundled fax/SMS module accept a file path from a logged-in user without authenticating the action or confining the path. The advisory says a low-privilege clinical or clerical account could read and write files on the server as the web user, and that configuration files holding database credentials are reachable. Versions before 8.3.0 are affected, and 8.3.0 is the patched release. The advisory notes this module family has had earlier file-write and authorization fixes, and that a third vendor client in the same module was already hardened.

Portal one-time tokens, rated critical. Per the advisory, published Sep 13, 2026, the one-time login component does not enforce its own single-use and access-count settings, and the optional six-digit PIN has no rate limiting. The advisory says a holder of a valid token could replay it for the token’s lifetime, up to 14 days in the invoice scenario, and open a full patient-portal session exposing protected health information. Versions before 8.4.0 are affected, with 8.4.0 as the fix. The advisory says earlier releases with the same code are likely also affected.

FHIR Person endpoint, rated moderate. Per the advisory, also published Sep 13, 2026, a patient-scoped API token is not confined to the patient’s own records when requesting Person resources, so a patient-portal user could read staff members’ personal details. It requires a valid patient token. Fixed in 8.4.0.

What to do

Upgrade to OpenEMR 8.4.0, which covers all three. If you cannot upgrade yet, the advisories point to reducing exposure: restrict access to the fax/SMS module and the FHIR API to those who need them, and treat outstanding portal invoice links as sensitive until the update lands. Rotate database credentials if you suspect the fax/SMS flaw was reached.

Analysis

This is a judgment, not a reported fact. The fax/SMS case is the instructive one: a hardening fix landed in one vendor client and did not travel to its siblings, and the module had been hit before. Patches that fix the instance rather than the class tend to come back as the next advisory. For anyone running a clinical system, the practical read is that a patient-facing portal and an API sitting next to staff data deserve the same patch cadence as anything internet-facing.

Related reading: OpenAM 16.1.4 fixes critical SSO account takeover flaws.