CVE-2026-25146: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-25146 is an information disclosure vulnerability in OpenEMR, a widely used open-source electronic health records and medical practice management application. Affecting versions 5.0.2 through 7.x (before 8.0.0), the flaw causes the gateway_api_key secret value to be rendered in plaintext within client-side JavaScript code across at least two payment-related pages. Disclosed on March 3, 2026, the vulnerability is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) and carries a CVSS v3.1 base score of 8.1 (High) per NVD, or 9.6 (Critical) per the GitHub Security Advisory (GitHub Advisory, Red Hat CVE).

The root cause is improper handling of sensitive configuration values in PHP server-side rendering: the gateway_api_key global variable — which stores payment gateway secrets such as Stripe API secret keys — is decrypted and directly embedded into client-facing JavaScript via json_encode($cryptoGen->decryptStandard($GLOBALS['gateway_api_key'])). This occurs in at least two files: interface/patient_file/front_payment.php (around line 765) and portal/portal_payment.php (around line 537), both of which are accessible to authenticated users including patients via the patient portal (GitHub Advisory, Patch Commit). The key was originally intended for Authorize.net (where the API Login ID is not sensitive), but the same gateway_api_key config field is reused for other gateways (e.g., Stripe) where it holds a true secret, making the disclosure universally dangerous regardless of gateway configuration (GitHub Advisory).

Any authenticated user — including patients with portal access — can retrieve the plaintext payment gateway API secret key by visiting the payment pages and inspecting the page source or browser developer tools. For gateways like Stripe, exposure of the secret API key can enable arbitrary financial transactions, unauthorized charges, refunds, or full account takeover of the payment gateway, leading to direct financial fraud and potential compromise of patient payment information (GitHub Advisory). Critically, patching OpenEMR alone is insufficient — any previously exposed keys must be rotated at the payment gateway provider, as attackers may have already captured and stored the leaked credentials for later use.

A proof-of-concept is publicly documented in the GitHub Security Advisory: an attacker with low-level access (e.g., a patient portal account) simply visits the payment pages and reads the apiKey JavaScript variable from the page source or browser inspector — no special tooling is required (GitHub Advisory). There is no evidence of active in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.03% (0.000300), indicating low current exploitation probability (Feedly). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify internet-facing OpenEMR instances running versions 5.0.2–7.x using search engines (Shodan, Censys) or by checking the OpenEMR version page.
2. Obtain portal access: Register or log in as a patient via the OpenEMR patient portal (low-privilege access is sufficient; no admin credentials required).
3. Navigate to payment page: Visit either the patient portal payment page (/portal/portal_payment.php) or the front payment interface (/interface/patient_file/front_payment.php) while authenticated.
4. Extract the API key: Open the browser's developer tools (F12 → Sources or Network tab) or view the page source. Locate the JavaScript variable var apiKey = "sk_live_..." (or equivalent) rendered in plaintext within the page's inline script.
5. Exploit the leaked key: Use the extracted secret API key to authenticate directly against the payment gateway API (e.g., Stripe, Authorize.net) to perform unauthorized transactions, issue refunds, enumerate customer data, or take over the payment gateway account (GitHub Advisory).

• Logs: Web server access logs showing authenticated requests to /portal/portal_payment.php or /interface/patient_file/front_payment.php from unexpected IP addresses or at unusual times; repeated access to these endpoints by patient-level accounts.
• Payment Gateway: Unexpected API calls, transactions, refunds, or account configuration changes in the payment gateway dashboard (e.g., Stripe Dashboard) originating from unfamiliar IP addresses or API clients not matching the OpenEMR server.
• Network: Outbound API calls to payment gateway endpoints (e.g., api.stripe.com) from hosts other than the OpenEMR server, potentially indicating use of a stolen key.
• Application: Review of page source or JavaScript bundles from the affected OpenEMR versions revealing var apiKey = "<plaintext_secret>" in rendered HTML responses.

Upgrade immediately to OpenEMR version 8.0.0 or later, which resolves the issue by restricting gateway_api_key rendering to only the Authorize.net code path (where it is not sensitive) and removing it from the general client-side output (Patch Commit). Rotate all payment gateway API keys at the provider (e.g., Stripe, Authorize.net) regardless of whether exploitation is confirmed, since keys may have been captured by any authenticated user since version 5.0.2. As a temporary workaround prior to upgrading, disable payment gateway functionality and remove API keys from the OpenEMR configuration, then restrict network access to the OpenEMR instance (GitHub Advisory).

The vulnerability was reported by security researcher "Firehed" and published via GitHub's coordinated disclosure process on March 3, 2026 (GitHub Advisory). The Hacker Wire covered the disclosure shortly after publication, and the CVE was picked up by automated tracking services including Vulners, CIRCL, and ENISA's EUVD (Feedly). Social media activity was observed on Bluesky and Mastodon from security news accounts, though no significant community debate or vendor controversy has been noted.