CVE-2026-25476: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-25476 is a session timeout bypass vulnerability in OpenEMR, a widely used open-source electronic health records (EHR) and medical practice management application. The flaw allows an attacker with a stolen session cookie to maintain unauthorized access indefinitely by appending skip_timeout_reset=1 to any request, bypassing the session expiration check in library/auth.inc.php. All OpenEMR versions prior to 8.0.0 are affected. The vulnerability was published on February 25, 2026, and fixed in version 8.0.0. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat CVE).

The root cause is Insufficient Session Expiration (CWE-613) in library/auth.inc.php. The vulnerable code wraps both the session expiration check (SessionTracker::isSessionExpired()) and the expiration timer reset (SessionTracker::updateSessionExpiration()) inside a single conditional block that is skipped entirely when skip_timeout_reset is present in the request. The intended design was to allow background polling pages (e.g., Patient Flow Board, Messages, Reminders) to skip only the timer reset — not the expiration check itself. The fix in commit 02a6a77 restructures the conditional so the expiration check always runs, and only the timer reset is conditionally skipped based on the skip_timeout_reset parameter (GitHub Advisory, Patch Commit).

Successful exploitation allows expired or stolen session cookies to access protected OpenEMR data indefinitely without re-authentication, directly impacting confidentiality of sensitive electronic health records and protected health information (PHI). Abandoned workstations remain active past configured inactivity timeouts, violating HIPAA and organizational session management policies. An attacker with a stolen session cookie can maintain persistent unauthorized access to patient records, medical histories, and practice management data by periodically sending requests with skip_timeout_reset=1, preventing automatic session termination (GitHub Advisory).

A proof-of-concept is publicly documented in the GitHub Security Advisory, demonstrating the bypass with a simple GET request appending ?skip_timeout_reset=1 to any protected OpenEMR endpoint. No active in-the-wild exploitation has been observed as of the time of disclosure. The vulnerability requires no privileges and no user interaction, making it trivially exploitable by any attacker who possesses a valid (even expired) session cookie. The EPSS score is approximately 0.032% (low probability of near-term exploitation). The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing OpenEMR instances (versions prior to 8.0.0) using search engines like Shodan or Censys, or by targeting known healthcare provider infrastructure.
2. Obtain a session cookie: Acquire a valid OpenEMR session cookie via phishing, network interception (e.g., on unencrypted HTTP), credential theft, or by waiting for an abandoned workstation session.
3. Confirm session expiration: Verify that the session cookie is expired by sending a normal request without the bypass parameter — e.g., GET /interface/main/main_screen.php with the stolen cookie. An expired session should redirect to the login page.
4. Apply the bypass: Resend the same request with ?skip_timeout_reset=1 appended: GET /interface/main/main_screen.php?skip_timeout_reset=1 with the expired session cookie. The expiration check is skipped and protected content is returned.
5. Maintain persistent access: Automate periodic requests with skip_timeout_reset=1 (e.g., via a script or cron job) to prevent the session from being invalidated server-side, enabling indefinite unauthorized access to patient records and PHI (GitHub Advisory).

• Network: HTTP GET or POST requests to OpenEMR endpoints (e.g., /interface/main/main_screen.php, /interface/patient_file/, or other protected pages) containing the skip_timeout_reset=1 query parameter from unexpected or external IP addresses; repeated automated requests at regular intervals with this parameter.
• Logs: OpenEMR access logs showing successful (HTTP 200) responses to protected pages with skip_timeout_reset=1 from sessions that should have expired based on configured inactivity timeout; absence of corresponding logout or timeout audit events in EventAuditLogger for long-running sessions.
• Application Audit Trail: Missing or absent session timeout/logout events in OpenEMR's audit log for sessions active well beyond the configured inactivity period; sessions active outside of normal business hours without corresponding user activity.
• Process/Behavior: Automated or scripted access patterns (e.g., requests at fixed intervals) to OpenEMR URLs with skip_timeout_reset=1, particularly from non-browser user agents or unusual source IPs (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0 or later, which restructures the session expiration logic so the expiration check always runs regardless of the skip_timeout_reset parameter (Patch Commit). For organizations unable to upgrade immediately, implement network-level controls to restrict access to OpenEMR instances (e.g., VPN or firewall rules limiting exposure), monitor web server and application logs for requests containing skip_timeout_reset=1 from unexpected sources, and consider enforcing additional authentication factors for access to sensitive patient data modules. Physical security controls (screen locks, workstation timeouts at the OS level) can partially mitigate the abandoned workstation risk until patching is complete (GitHub Advisory).

The vulnerability was reported by researchers simecek (reporter) and pavelkohout396 (analyst) and published by OpenEMR maintainer bradymiller via GitHub Security Advisories on February 25, 2026. The issue was noted in the context of a broader research effort, with Aisle reporting 38 critical security vulnerabilities in healthcare software used by 100,000 providers, which included this finding (Aisle Blog). Social media mentions appeared on Mastodon and Bluesky shortly after disclosure, reflecting community awareness of the healthcare data exposure risk (GitHub Advisory).