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

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

Which versions of Openemr are affected by CVE-2026-33910?

OpenEMR installations (versions up to 8.0.0.2) face a high-risk SQL injection vulnerability that could allow privileged insiders to breach patient database confidentiality and integrity.

How to fix or mitigate CVE-2026-33910?

Within 24 hours: Identify all OpenEMR instances and their versions; restrict database account privileges to least-privilege principles; enable database query logging and monitoring. Within 7 days: Implement WAF rules to block SQL injection patterns in patient selection requests; conduct access review of high-privilege accounts; document all compensating controls. Within 30 days: Contact OpenEMR vendor for patch ETA; evaluate network segmentation options to isolate OpenEMR; consider temporary restriction of patient selection feature to essential personnel only until patch availability.

Openemr CVE-2026-33910

HIGH

SQL Injection (CWE-89)

2026-03-25 GitHub_M

SQLi Openemr

7.2

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.2 HIGH

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

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

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Mar 25, 2026 - 23:02 vuln.today

CVE Published

Mar 25, 2026 - 22:41 nvd

HIGH 7.2

DescriptionGitHub Advisory

OpenEMR is a free and open source electronic health records and medical practice management application. Versions up to and including 8.0.0.2 contain a SQL injection vulnerability in the patient selection feature that can be exploited by authenticated attackers. The vulnerability exists due to insufficient input validation in the patient selection feature. Version 8.0.0.3 contains a patch.

AnalysisAI

OpenEMR versions up to and including 8.0.0.2 contain a SQL injection vulnerability in the patient selection feature that allows authenticated attackers with high privileges to execute arbitrary SQL commands. The vulnerability stems from insufficient input validation and can lead to complete compromise of confidentiality, integrity, and availability of the healthcare database. No evidence of active exploitation (not in CISA KEV) or public proof-of-concept is currently available.

Technical ContextAI

OpenEMR is an open-source electronic health records (EHR) and medical practice management application used in healthcare environments. The vulnerability is classified as CWE-89 (SQL Injection), occurring when user-supplied input in the patient selection feature is not properly sanitized before being incorporated into SQL queries. The affected product is identified via CPE cpe:2.3:a:openemr:openemr:*:*:*:*:*:*:*:* covering all versions up to 8.0.0.2. SQL injection vulnerabilities allow attackers to manipulate database queries, potentially bypassing authentication, extracting sensitive patient data protected under regulations like HIPAA, modifying medical records, or executing administrative operations on the database server.

RemediationAI

Upgrade OpenEMR to version 8.0.0.3 or later, which contains a security patch that addresses the SQL injection vulnerability as documented in the release notes at https://github.com/openemr/openemr/releases/tag/v8_0_0_3. The specific remediation commit can be reviewed at https://github.com/openemr/openemr/commit/73db3264aed253684532839380cae3b0a56c83d2 for technical verification. Until patching can be completed, organizations should review and restrict user accounts with high-privilege access to the patient selection feature, implement additional monitoring for suspicious database queries or unusual data access patterns, and ensure comprehensive audit logging is enabled to detect potential exploitation attempts. Given that this vulnerability requires authenticated high-privilege access, focusing on proper access control and principle of least privilege can provide interim risk reduction.