☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-26476

CVE-2024-26476 Privilege Escalation in Openemr
📅 PUBLISHED: 2024-02-28 00:00 UTC 🔄 UPDATED: 2026-09-23 20:37 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.41%
👁️
0.41% probability
10.3× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: Global License: Open Source
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-26476 is a privilege escalation vulnerability in OpenEMR, an open-source electronic health records and medical practice management application. The flaw exists in the ereq_form.php component, where a remote attacker can exploit a crafted script passed via the formid parameter to escalate their privileges. This vulnerability affects versions prior to 7.0.2. While no public proof-of-concept (PoC) or exploit code is currently available, the nature of the vulnerability (privilege escalation via a parameter) suggests a potential for unauthorized access to sensitive patient data and administrative functions. The CVSS score is listed as 0.0, indicating incomplete scoring data, but the impact is considered high due to the potential for full system compromise.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

OpenEMR is a PHP-based application. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application code. Organizations should verify the integrity of their OpenEMR installation and ensure they are using a trusted source for updates.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or error in the NVD data. Based on the description and common privilege escalation vulnerabilities, a reasonable estimated CVSS v3.1 vector would be:

  • Attack Vector (AV): Network (N) – The attack is performed remotely.
  • Attack Complexity (AC): Low (L) – No special conditions are required.
  • Privileges Required (PR): Low (L) – The attacker likely needs some level of access (e.g., a standard user account) to exploit the formid parameter.
  • User Interaction (UI): None (N) – No user interaction is required.
  • Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
  • Confidentiality (C): High (H) – Full access to patient records and system data.
  • Integrity (I): High (H) – Ability to modify records, configurations, or inject malicious code.
  • Availability (A): High (H) – Potential to disrupt services or delete data.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H Estimated Base Score: 8.8 (High)

Threat Level: High. The vulnerability allows privilege escalation, which can lead to a complete compromise of the OpenEMR instance and exposure of sensitive healthcare data.

Deep Dive & Mechanics

The vulnerability resides in the ereq_form.php component. This file is part of OpenEMR's request management system, likely used for handling electronic requisition forms. The formid parameter is used to specify which form to load or process.

The flaw is a classic Improper Privilege Management (CWE-269). The application fails to properly verify that the user making the request has the necessary permissions to access or manipulate the form identified by the formid parameter. By crafting a malicious script or manipulating the formid value, an attacker with low-level privileges (e.g., a nurse or receptionist account) can escalate to an administrator-level role.

The attack flow is as follows:

  1. An attacker authenticates to OpenEMR with a low-privilege account.
  2. The attacker sends a specially crafted HTTP request to ereq_form.php with a manipulated formid parameter.
  3. The application processes the request without proper authorization checks, allowing the attacker to perform actions reserved for higher-privilege users (e.g., creating admin accounts, modifying system settings, accessing all patient records).
  4. The attacker gains elevated privileges and can then fully compromise the system.

Vulnerable vs. Patched Code

Since no specific code diff is publicly available, this section provides a conceptual comparison.

Vulnerable Code (Conceptual - Pre-7.0.2):

<?php
// ereq_form.php - Vulnerable version
$form_id = $_GET['formid'];
// No privilege check before processing the form
$form_data = getFormData($form_id);
processForm($form_data);
?>

Patched Code (Conceptual - 7.0.2+):

<?php
// ereq_form.php - Patched version
$form_id = $_GET['formid'];
// Added privilege check
if (!checkUserPrivilege($form_id)) {
    die("Access denied: Insufficient privileges.");
}
$form_data = getFormData($form_id);
processForm($form_data);
?>

The patched version introduces an authorization check (checkUserPrivilege()) before processing the form data, ensuring that the user has the appropriate role to access the specified form.

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

  1. Target: Install OpenEMR version 7.0.1 or earlier on a local VM (e.g., Ubuntu 22.04 with Apache, MySQL, PHP).
  2. Attacker: Kali Linux VM.
  3. Credentials: Create a low-privilege user account (e.g., "nurse" with role "Clinician").

Exploitation Steps:

  1. Log in to OpenEMR as the low-privilege user.
  2. Intercept a request to ereq_form.php using Burp Suite or a similar proxy.
  3. Modify the formid parameter to a value that corresponds to an administrative function or a form that requires higher privileges. For example:
    GET /openemr/ereq_form.php?formid=admin_create_user
    
  4. Observe the response. If the application processes the request without error, the privilege escalation is successful.
  5. Use this to create a new admin user or directly access sensitive data.

Note: Since no public exploit exists, this is a conceptual demonstration. The exact parameter manipulation will depend on the application's logic.

Blue Team (Defensive)

Detection:

  1. Monitor Logs: Look for unusual access patterns to ereq_form.php from low-privilege users.
  2. Parameter Anomalies: Detect requests with unexpected or suspicious formid values (e.g., containing SQL injection patterns, path traversal, or administrative keywords).
  3. Privilege Escalation Alerts: Alert on any user who suddenly performs actions that are outside their defined role (e.g., a "Clinician" creating a new user).

Hunting:

  • Search web server logs for requests to ereq_form.php with formid parameters that do not match expected patterns for the requesting user's role.
  • Correlate with authentication logs to identify users who may have been compromised.

Indicators of Compromise (IOCs)

  • Network:
    • HTTP requests to /openemr/ereq_form.php with unusual formid parameters.
    • Repeated failed access attempts followed by a successful privilege escalation.
  • Host:
    • New user accounts created with administrative privileges.
    • Unusual entries in OpenEMR's audit log (e.g., audit.sql or log.sql).
    • Modified system configuration files (e.g., config.php).
  • File:
    • Suspicious files uploaded to the openemr directory (e.g., webshells).
    • Changes to ereq_form.php or related files (if an attacker modifies the source).

Detection Engineering

YARA Rule

rule CVE_2024_26476_OpenEMR_PrivEsc {
    meta:
        description = "Detects potential exploitation of CVE-2024-26476 in OpenEMR ereq_form.php"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-26476"
        hash = "unknown"
    strings:
        $s1 = "ereq_form.php" nocase
        $s2 = "formid=" nocase
        $s3 = "admin" nocase
        $s4 = "create" nocase
        $s5 = "user" nocase
    condition:
        all of ($s1, $s2) and 1 of ($s3, $s4, $s5)
}

Sigma Rule

title: CVE-2024-26476 - OpenEMR Privilege Escalation via ereq_form.php
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects suspicious requests to ereq_form.php with potential privilege escalation attempts.
author: Valters IT
date: 2024/10/27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-26476
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains: "ereq_form.php"
        cs-uri-query|contains: "formid="
    keywords:
        - "admin"
        - "create"
        - "user"
        - "delete"
        - "config"
    condition: selection and keywords
falsepositives:
    - Legitimate administrative actions from authorized users
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-26476 - OpenEMR Privilege Escalation Attempt"; flow:to_server,established; content:"ereq_form.php"; http_uri; content:"formid="; http_uri; pcre:"/(admin|create|user|delete|config)/i"; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade: Update OpenEMR to version 7.0.2 or later. This is the only confirmed fix.
  2. Isolate: If immediate patching is not possible, restrict network access to the OpenEMR web interface to trusted IP addresses only.
  3. Review Accounts: Audit all user accounts and remove any that are not necessary. Enforce the principle of least privilege.

Long-Term Mitigations:

  1. Web Application Firewall (WAF): Deploy a WAF with rules to block suspicious requests to ereq_form.php with unusual formid parameters.
  2. Input Validation: Ensure all user-supplied parameters are validated and sanitized.
  3. Regular Audits: Conduct regular security audits and code reviews of custom or third-party OpenEMR modules.
  4. Monitoring: Implement the detection rules provided above to alert on potential exploitation attempts.

Valters IT – Securing Healthcare, One Patch at a Time.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-26476/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.