Drug Recommendation System CVE-2026-94033

Requires an authenticated session able to reach the User Management add_user function at /drug_recommender/Admin/add_user (PR:L, an administrative feature), and requires passive user interaction (UI:P) - a victim must subsequently view the page where the injected txtname/txtemail/txtpassword value is rendered for the script to fire. Impact is limited to integrity within the browser context (VI:L; no confidentiality or availability impact). Limiting factors: the target is a niche SourceCodester application with essentially no production deployment, exploitation needs prior authentication, and the script only executes when another user renders the stored value.

This is a low-real-risk finding despite the network attack vector. The vendor CVSS 4.0 base score is 5.1 (medium), and the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P tells a modest story: exploitation requires an authenticated account (PR:L) and passive user interaction (UI:P - a victim must view the injected content), with impact limited to integrity only (VI:L) and no confidentiality or availability effect. The affected code path is /drug_recommender/Admin/add_user in the User Management component, an administrative feature, which further constrains who can reach the injection point. Exploitation status is 'publicly available exploit code exists' (a GitHub POC by KaranParelkar is referenced and VulDB flags E:P/'Proof-of-Concept'), but there is NO EPSS score, NO CISA KEV listing, and NO evidence of active exploitation - POC availability must not be conflated with in-the-wild use. The signals are internally consistent (network XSS, authenticated, low integrity impact), so no contradiction to flag; the primary caveat is that this is a SourceCodester hobbyist/tutorial application with negligible production footprint, making it a CVE-mill entry rather than a genuine defensive priority.

An authenticated low-privileged user (or an admin with a foothold) submits the add_user form with a malicious script payload in the txtname, txtemail, or txtpassword parameters. The payload is stored and later rendered without proper output encoding, so when another user or administrator views the affected page in the User Management interface, the script executes in their browser session. A public proof-of-concept for this exact endpoint is available on GitHub.