Description

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.2.0, interface/modules/custom_modules/oe-module-faxsms/src/Controller/SignalWireClient.php decrypts a selected patient document with Document::get_data() and SignalWireClient::uploadFileForFax() writes the plaintext bytes under sites/{siteId}/fax. The module returns the resulting public URL to SignalWire, protects it only with a predictable uniqid() filename, and never removes the staged file. An unauthenticated network actor who obtains or guesses the URL can retrieve persistent patient documents even when drive encryption is enabled. This issue is fixed in version 8.2.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-11-05T20:17:59.507Z",
  "pubdate": "2026-11-05T20:17:59.507Z",
  "executiveSummary": "OpenEMR versions prior to 8.2.0 contain a critical vulnerability in the oe-module-faxsms module, leading to the unauthorized disclosure of sensitive patient medical documents.\nThe vulnerability stems from the insecure handling of decrypted document data, where plaintext files are written to a public-facing web directory with predictable naming conventions.\nAn unauthenticated, remote attacker can retrieve these sensitive files by guessing the predictable uniqid() filename or discovering the URL, bypassing existing drive-level encryption protocols.\nBecause the system fails to purge these temporary files, the application creates a persistent data leak that does not require prior authentication or elevated privileges to exploit.\nThe risk to the organization is significant, as it facilitates unauthorized access to Protected Health Information (PHI), leading to potential HIPAA non-compliance and exposure of patient privacy.",
  "technicalDetails": "The vulnerability resides within the interface/modules/custom_modules/oe-module-faxsms/src/Controller/SignalWireClient.php file. The flaw originates from the improper lifecycle management of decrypted document data. When the module initiates a fax operation, it calls Document::get_data() to retrieve the stored document, which is subsequently decrypted by the application.\nThe component SignalWireClient::uploadFileForFax() then proceeds to write these decrypted, plaintext bytes to the directory sites/{siteId}/fax. This directory is publicly accessible, and the application generates the filename using the standard PHP uniqid() function. Because uniqid() is based on the system clock rather than a cryptographically secure pseudo-random number generator (CSPRNG), the generated filename is highly predictable to an attacker who understands the timing of the request.\nThe attack flow follows a predictable pattern: (1) An attacker monitors or targets requests to the fax module. (2) Even without authentication, an attacker can brute-force or guess the generated URL of the plaintext file stored in the public web space. (3) The application serves the plaintext patient document directly to the unauthorized requester. (4) The server persists these files indefinitely, as there is no automated cleanup or deletion mechanism, creating a permanent repository of exposed medical records.\nThis vulnerability effectively renders drive-level encryption useless for data in transit within the application context, as the encryption is stripped at the application layer and the resulting data is stored in a non-protected, publicly reachable location. The impact is a complete bypass of confidentiality controls for patient documentation handled by the fax/SMS module. Exploitation is trivial, requiring only network access to the web server and the ability to guess the predictable filename, with no requirement for existing session tokens or prior system access."
}