What is the CVSS score of CVE-2026-34055?

CVE-2026-34055 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of PHP are affected by CVE-2026-34055?

OpenEMR installations are vulnerable to unauthorized access and modification of patient medical records due to an authentication bypass flaw affecting versions prior to 8.0.0.3.

How to fix or mitigate CVE-2026-34055?

Within 24 hours: Identify all OpenEMR instances and their versions; isolate or restrict network access to patient notes functionality if possible. Within 7 days: Implement compensating controls (WAF rules, access logging, role-based restrictions); conduct audit of patient notes access logs for unauthorized activity. Within 30 days: Plan upgrade to version 8.0.0.3 or later; coordinate with vendor on patch availability timeline; complete forensic review of access logs to identify potential breaches.

PHP CVE-2026-34055

HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-03-26 security-advisories@github.com

PHP Authentication Bypass

8.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.1 HIGH

AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Mar 26, 2026 - 00:22 vuln.today

CVE Published

Mar 26, 2026 - 00:16 nvd

HIGH 8.1

DescriptionGitHub Advisory

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0.3, the legacy patient notes functions in library/pnotes.inc.php perform updates and deletes using WHERE id = ? without verifying that the note belongs to a patient the user is authorized to access. Multiple web UI callers pass user-controlled note IDs directly to these functions. This is the same class of vulnerability as CVE-2026-25745 (REST API IDOR), but affects the web UI code paths. Version 8.0.0.3 patches the issue.

AnalysisAI

OpenEMR contains an Insecure Direct Object Reference (IDOR) vulnerability in the patient notes functionality where authenticated users can modify or delete notes belonging to any patient without proper authorization checks. This affects OpenEMR versions prior to 8.0.0.3 and allows attackers with low-level privileges to access, modify, or delete sensitive medical records they should not have access to. The vulnerability has a CVSS score of 8.1 with high confidentiality and integrity impact, though there is no current evidence of active exploitation in the wild or public proof-of-concept code.

Technical ContextAI

The vulnerability exists in the legacy patient notes functions within library/pnotes.inc.php in OpenEMR, a PHP-based open source electronic health records (EHR) and medical practice management system. The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), where database operations perform updates and deletes using WHERE id = ? clauses without validating that the authenticated user has authorization to access notes for that particular patient. Multiple web UI code paths accept user-controlled note IDs and pass them directly to these vulnerable functions, creating an Insecure Direct Object Reference. This represents a web UI variant of the same vulnerability class previously identified as CVE-2026-25745 in the REST API.

RemediationAI

Upgrade OpenEMR to version 8.0.0.3 or later, which contains patches for this IDOR vulnerability as documented in the release notes at https://github.com/openemr/openemr/releases/tag/v8_0_0_3. The specific fix is implemented in commit 214c9b4585a6f1c8c22750172d47f0e258fec0bf available at https://github.com/openemr/openemr/commit/214c9b4585a6f1c8c22750172d47f0e258fec0bf. Until patching is possible, implement strict role-based access controls, audit user permissions to ensure principle of least privilege, monitor patient note access patterns for anomalies, and restrict network access to the OpenEMR instance to trusted IP ranges only. Given the sensitivity of medical records, prioritize this upgrade and conduct a security audit to identify any unauthorized access that may have occurred prior to patching.