Hospital Management System EUVD-2026-35056

Exploitation requires possession of a valid low-privilege authenticated session on the Hospital Management System - this is confirmed by CVSS PR:L in the vector. The attacker must have access to the patient admission workflow (the /addpatient.php endpoint), which is the specific application feature containing the vulnerable parameter. No non-default configuration is required; any installation of version 1.0 with the addpatient feature accessible is vulnerable by default once authenticated. Exploitation is bounded by the authentication barrier (PR:L) - unauthenticated attackers cannot directly reach this parameter. Impact is further limited to the application's own database scope, as the CVSS subsequent component metrics are all None (SC:N/SI:N/SA:N), ruling out lateral movement to the underlying OS or other systems via this vector alone.

The CVSS 4.0 score of 2.1 is low and internally consistent: exploitation requires low-privilege authentication (PR:L), and all impact metrics are rated Low with no subsequent component impact (SC:N/SI:N/SA:N), indicating the SQLi's blast radius is confined to the application's own database context - not a full database server takeover or RCE vector. The E:P modifier (proof-of-concept exists) is the primary risk amplifier, reducing attacker skill requirements. No EPSS data was provided, so probability-of-exploitation-in-the-wild cannot be quantified. KEV status is not confirmed. Despite the low score, the healthcare deployment context introduces elevated regulatory risk - even a VC:L (low confidentiality impact) SQLi against patient admission records can implicate HIPAA breach notification obligations in US deployments. No conflicting signals exist between the CVSS vector and the description; both consistently indicate authenticated, remote, low-impact exploitation.

A publicly available proof-of-concept exists (GitHub: ltranquility/vuln_submit/issues/15). An attacker with a valid low-privilege account on the hospital system navigates to the patient admission form and submits an HTTP POST request to /addpatient.php with a SQL payload injected into the admissiontme parameter (e.g., a time-based blind or UNION-based injection), causing the backend database to return or modify patient records beyond the attacker's intended access scope.