Description

OpenEMR is a free and open source electronic health records and medical practice management application. From 6.0.0 until 8.3.0, interface/globals.php uses the unauthenticated authUser login parameter to populate temp_authuserid and load that account's user_settings before authentication succeeds. Existing usernames can therefore cause an additional database query and may apply visible customized settings, while nonexistent usernames skip that behavior. A remote unauthenticated actor can use timing or page differences to enumerate valid accounts for later credential attacks. This issue is fixed in version 8.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-11-05T20:17:38.033Z",
  "pubdate": "2026-11-05T20:17:38.033Z",
  "executiveSummary": "OpenEMR versions 6.0.0 through 8.3.0 are susceptible to an unauthenticated account enumeration vulnerability within the 'interface/globals.php' file. The vulnerability arises from the improper handling of the 'authUser' parameter, which allows an unauthenticated remote attacker to verify the existence of valid system usernames. By observing timing discrepancies or variations in the rendered application state (specifically the loading of user-specific settings), an attacker can distinguish between valid and invalid credentials. This information disclosure flaw facilitates targeted brute-force or credential-stuffing attacks against identified accounts, significantly lowering the barrier for unauthorized system access. The vulnerability requires no authentication to exploit and leverages existing application logic intended for post-authentication sessions, posing a moderate to high risk to medical practice environments relying on OpenEMR for sensitive patient data management.",
  "technicalDetails": "The vulnerability resides in the core initialization script 'interface/globals.php' of OpenEMR. In the affected versions, the application processes the 'authUser' HTTP parameter prior to the completion of the authentication handshake. Specifically, the logic consumes this parameter to populate the 'temp_authuserid' variable and subsequently triggers a database query to retrieve user-specific settings before verifying the validity of a login session.\nThe root cause is a breakdown in the secure separation of pre-authentication and post-authentication states. The application prematurely attempts to load user profile configurations based on input provided in the 'authUser' parameter. This design flaw creates an observable side-channel. When an attacker supplies a valid username in the 'authUser' parameter, the application executes a database lookup for that user and attempts to apply their customized environment settings. Conversely, if a nonexistent username is provided, the database query returns null, and the application skips the setting-loading routine entirely.\nThe attack flow proceeds as follows: First, an unauthenticated actor sends crafted HTTP requests containing the 'authUser' parameter to the login endpoint. Second, the server-side code in 'interface/globals.php' processes this input by initiating a database query. Third, the attacker measures the response time (timing attack) or analyzes the HTTP response for subtle changes in the HTML/CSS structure indicative of applied user settings. If the processing time is significantly longer or the page displays specific elements associated with a user's customized configuration, the attacker confirms the existence of the account. If the response is uniform and fast, the account is likely nonexistent.\nThis vulnerability is classified as an Information Disclosure/Enumeration issue. Because the application logic differentiates its internal behavior based on the validity of the username before security controls are enforced, it provides a reliable oracle for attackers to perform reconnaissance. This intelligence significantly increases the efficiency of subsequent password guessing attacks, as the attacker can prune their wordlist to include only valid, confirmed usernames. The flaw persists across the specified versions until the application logic in 'interface/globals.php' is modified to restrict user-specific setting lookups until a successful authentication token is verified."
}