CVE-2026-124479 in OpenEMR
Summary
by MITRE • 11/08/2026
OpenEMR before 8.4.0 contains an arbitrary local file read vulnerability in REST document download, where the controller passes stored uploaded document bytes to Symfony's BinaryFileResponse as a filesystem path instead of returning them as content. Authenticated users with document upload and download access can upload a document containing an absolute pathname, such as the sqlconf.php location, then download it to read server files and recover database credentials.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in OpenEMR versions prior to 8.4.0 represents a critical flaw within its REST API implementation for handling document downloads. This issue stems from an improper input validation mechanism where the application fails to distinguish between file content and file system paths when processing requests for stored documents. Specifically, the controller responsible for serving downloaded files incorrectly passes the raw bytes of an uploaded document directly into Symfony's BinaryFileResponse class as a filesystem path argument rather than treating them as the actual content payload intended for transmission. This architectural misconfiguration allows an attacker to manipulate the server-side file retrieval logic by exploiting how the framework interprets the input data, effectively bypassing standard access controls that would normally restrict reading only from designated document storage directories.
From a technical perspective, this flaw is classified under CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-94 Improper Control of Generation of Code or Commands where code is referred to as path traversal. The core issue lies in the assumption that uploaded documents contain only valid document data, ignoring the possibility that an attacker could embed absolute file paths within the binary content itself. When the application attempts to serve this maliciously crafted payload via BinaryFileResponse, it interprets the embedded string not as text but as a directive pointing to a specific location on the server's filesystem. Consequently, instead of returning the document bytes, the server reads and returns the contents of whatever file path was encoded within the uploaded artifact. This behavior transforms what should be a simple data retrieval operation into an arbitrary local file read vulnerability, enabling unauthorized access to sensitive system files that are typically outside the scope of user-accessible resources.
The operational impact of this vulnerability is severe for any deployment relying on OpenEMR for electronic health records or similar critical infrastructure. An authenticated attacker with permissions to upload and download documents can exploit this flaw to extract highly confidential information from the server environment. By uploading a document containing absolute paths such as /etc/passwd, configuration files like sqlconf.php, or other sensitive data stores, the attacker can subsequently trigger the download endpoint to retrieve these contents directly in their browser or via automated scripts. This capability facilitates credential theft, particularly database credentials stored in configuration files, which can then be used for further lateral movement within the network. The ability to read arbitrary local files also aids in reconnaissance activities, allowing attackers to map out server architecture and identify additional attack vectors based on software versions and installed packages found in system files.
Mitigation strategies must address both immediate remediation and long-term defensive posture improvements. The primary solution is to upgrade OpenEMR to version 8.4.0 or later where this vulnerability has been patched by correcting the handling of document bytes within the REST controller logic. Until an upgrade can be performed, administrators should implement strict input validation at the application layer to ensure that uploaded files do not contain absolute path strings and restrict file uploads to specific allowed extensions with sanitized filenames. Additionally, deploying a Web Application Firewall capable of detecting path traversal patterns in HTTP requests may provide temporary protection against exploitation attempts. From a broader security architecture standpoint, this incident underscores the importance of adhering to secure coding practices regarding file handling operations as outlined by OWASP guidelines and ensuring that third-party libraries like Symfony are integrated with appropriate safeguards against misinterpretation of user-supplied data. Regular penetration testing focused on API endpoints can further help identify similar logic flaws before they are exploited in production environments.