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

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

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

OpenEMR deployments running versions prior to 8.0.0.3 contain a SQL injection vulnerability in the CAMOS form module that allows low-privilege authenticated users to execute arbitrary database…

How to fix or mitigate CVE-2026-33917?

Within 24 hours: inventory all OpenEMR instances and confirm running versions; identify systems below 8.0.0.3 and restrict CAMOS form access to administrative users only pending patching. Within 7 days: apply vendor patch to upgrade all affected OpenEMR instances to version 8.0.0.3 or later; validate patches in non-production environments first. Within 30 days: conduct audit of CAMOS form usage logs for the past 90 days to detect any unauthorized SQL activity; review database access controls and user privilege assignments.

PHP CVE-2026-33917

HIGH

SQL Injection (CWE-89)

2026-03-25 GitHub_M

PHP SQLi Openemr

8.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.8 HIGH

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

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

CVSS VectorGitHub Advisory

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Mar 25, 2026 - 23:47 vuln.today

CVE Published

Mar 25, 2026 - 23:31 nvd

HIGH 8.8

DescriptionGitHub Advisory

OpenEMR is a free and open source electronic health records and medical practice management application. Versions prior to 8.0.0.3 contais a SQL injection vulnerability in the ajax_save CAMOS form that can be exploited by authenticated attackers. The vulnerability exists due to insufficient input validation in the ajax_save page in the CAMOS form. Version 8.0.0.3 patches the issue.

AnalysisAI

SQL injection in OpenEMR versions prior to 8.0.0.3 enables authenticated attackers to execute arbitrary SQL commands through the CAMOS form's ajax_save functionality, potentially leading to complete database compromise including extraction of sensitive health records, data modification, and service disruption. The vulnerability requires low-privilege authentication (PR:L) with no user interaction (UI:N) and is network-exploitable (AV:N), though EPSS assigns only 0.03% (8th percentile) exploitation probability and no public exploit identified at time of analysis. Vendor-released patch available in version 8.0.0.3.

Technical ContextAI

OpenEMR is an open-source electronic health records (EHR) and medical practice management system widely deployed in healthcare settings. The vulnerability affects cpe:2.3:a:openemr:openemr:*:*:*:*:*:*:*:* (versions prior to 8.0.0.3) and is classified as CWE-89 (SQL Injection), indicating insufficient input validation and sanitization in the ajax_save endpoint of the CAMOS (Computer Aided Medical Ordering System) form module. Attackers can inject malicious SQL commands through form parameters that are improperly handled during database queries, allowing direct interaction with the underlying database layer. The CAMOS module is used for clinical documentation and order entry, making it a critical component that handles sensitive patient health information subject to HIPAA and similar regulations.

RemediationAI

Upgrade OpenEMR to version 8.0.0.3 or later, which contains the fix for this SQL injection vulnerability as documented in the release notes at https://github.com/openemr/openemr/releases/tag/v8_0_0_3. The specific remediation code is available in commit 4d48821d18e4125508d8217c43b09233c7f7e17f at https://github.com/openemr/openemr/commit/4d48821d18e4125508d8217c43b09233c7f7e17f for administrators who need to verify the patch or apply it manually. Until patching is completed, implement defense-in-depth measures including restricting access to the CAMOS form module to only essential personnel, enforcing strong authentication policies, monitoring database query logs for SQL injection patterns, and deploying web application firewall rules to detect and block SQL injection attempts targeting the ajax_save endpoint. Review and rotate database credentials as a precautionary measure if exploitation is suspected.