hosp_order CVE-2026-96551

Exploitation requires an authenticated hosp_order user to be logged in with an active session and to be tricked into visiting an attacker-controlled page or clicking a crafted link (UI:P). The vulnerable endpoint in CommonUserController.java must lack anti-CSRF token validation. There is no fixed version - the product does not use versioning and the maintainer has not responded - so no patched configuration exists. Exploitation is limited by the need for victim interaction, a concurrent authenticated session, and the vanishingly small deployment base of this obscure application.

This is a low real-world priority despite public exploit disclosure. The CVSS 4.0 base score of 2.1 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N) correctly reflects a CSRF flaw whose only impact is low integrity (VI:L) - an attacker cannot read data (VC:N) or degrade availability (VA:N), and success requires a logged-in victim to be lured into a passive interaction (UI:P). SSVC-style exploit maturity is E:P (proof-of-concept), consistent with the VulDB-referenced GitHub issue #122; there is no EPSS score, no CISA KEV listing, and no evidence of active exploitation. The signals are internally consistent: network vector but user-interaction-gated, low technical impact, PoC-only maturity. The dominant risk-reducer is not the exploit mechanics but the product itself - hosp_order is an obscure, unversioned GitHub project with no discernible production footprint, so even a working CSRF has almost no addressable attack surface. No conflicting signals; the main caveat is that the specific state-changing action forged in CommonUserController.java is not detailed in the description, so exact business impact is inferred from the CWE-352 classification.

An attacker hosts a malicious web page (or emails a link) containing an auto-submitting form or crafted request targeting an unprotected state-changing endpoint in CommonUserController.java. When an authenticated hosp_order user visits the page while their session is active, the browser silently submits the forged request, performing an action as the victim. A public proof-of-concept exists (VulDB #408953, referencing GitHub issue #122).