HospitalManagement EUVD-2026-82988

Exploitation requires a victim who is currently authenticated to a HospitalManagement instance to be tricked into loading attacker-controlled web content (UI:P/passive interaction) while their session is active - the app must lack anti-CSRF tokens on the targeted state-changing endpoint (the underlying weakness). Limiting factors: it only works against logged-in users, achieves only limited integrity impact (no data theft or service disruption), depends on social engineering to deliver the forged request, and there is no confirmed fixed version because the rolling-release project maintainer has not responded.

This is a genuinely low-priority issue whose real-world risk sits well below what a raw 5.3 might suggest. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P/VC:N/VI:L/VA:N) describes a network-reachable CSRF requiring passive user interaction (a logged-in victim must visit an attacker-controlled page), with only limited integrity impact and no confidentiality or availability impact - the classic profile of a CSRF flaw. The E:P (Proof-of-Concept) exploit maturity aligns with the intelligence signal that a public PoC exists (VulDB-linked GitHub issue #6). No EPSS score is provided and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation - status is best characterized as: publicly available exploit code exists, but no public exploitation in the wild. Signals are internally consistent (network CSRF + PoC + low integrity impact); the main tension is between a network attack vector and the practical requirement of a specific authenticated victim being socially engineered, which sharply limits scalability. The affected product is an obscure individual-developer GitHub project (gedelumbung/HospitalManagement) on a rolling-release model with no version pinning, and the maintainer has not responded to the report - so no fix is confirmed available.

An attacker crafts a malicious web page or email containing a hidden auto-submitting form targeting a state-changing endpoint of the HospitalManagement app. When an already-authenticated user (e.g., an admin or staff member) is lured into visiting it, the browser silently submits the forged request using the victim's session, performing an unwanted action such as creating or modifying a record. A public proof-of-concept for this CSRF is available via the referenced GitHub issue.