hosp_order EUVD-2026-84376

Exploitation requires the target to be running sfturing hosp_order (at or before commit 627f426331da8086ce8fff2017d65b1ddef384f8) with the Public Search Handlers reachable, and requires user interaction (UI:P): a victim must open an attacker-crafted request/URL whose 'Search' argument carries the payload. No authentication is required (PR:N) and the attack is remote, but the reflected nature means it is limited to whatever the victim's browser session can do in the app origin - no server-side confidentiality or availability impact. The practical limiter is the near-zero real-world deployment of this project rather than any configuration prerequisite.

This is a reflected cross-site scripting flaw (CWE-79) in sfturing's hosp_order, an obscure open-source hospital ordering project on GitHub, via the unsanitized 'Search' argument in HospitalController.java (Public Search Handlers). The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N, base 5.3) is internally consistent with a reflected XSS: network-reachable, low complexity, no privileges, but requiring passive victim interaction (UI:P) and yielding only low integrity impact with no confidentiality or availability loss. POC availability is confirmed (publicly available via the GitHub issue report), but a public POC is NOT the same as active exploitation: there is no CISA KEV listing and no EPSS score in the input, so exploitation status is best described as publicly available exploit code exists, not in-the-wild. The signals are consistent rather than conflicting - a genuine but low-impact issue. The dominant risk-reducer is deployment footprint: this is a hobby-scale project with no meaningful production presence, and it remains unpatched (vendor informed via issue but unresponsive). Net: a real, verified but low-severity XSS whose practical priority is minimal outside anyone who actually runs this specific project.

An attacker crafts a URL to the hospital public search endpoint with a malicious payload in the 'Search' parameter and lures an authenticated or anonymous user into clicking it. When the response reflects the input unsanitized, the script executes in the victim's browser in the application's origin, enabling session-token theft or actions on the victim's behalf. A public exploit reference already exists in the project's GitHub issue #118.