Hotel and Tourism Reservation System CVE-2026-10289

The application must be network-accessible (AV:N) and the /ht/tour.php reservation form must be reachable by the attacker - no authentication is required to submit the malicious payload (PR:N confirmed by CVSS vector). Exploitation of the full impact requires a second victim (UI:R): a user with an active browser session must load the page containing the stored payload for script execution to occur, meaning the attacker cannot achieve impact purely unilaterally against a single target. The four vulnerable parameters (name, email, people, number) must be processed and subsequently rendered by the application without sanitization - this is the default behavior of version 1.0. No special server configuration or non-default feature enablement is indicated. Exploitation is limited in scope (S:U), meaning the attacker cannot leverage this vulnerability to pivot to the underlying server or other application contexts beyond the victim's browser session.

The CVSS 3.1 base score of 4.3 (Medium) accurately reflects the limited direct impact: AV:N (network-exploitable) and AC:L (no special conditions) lower the barrier to exploitation, while PR:N (no authentication required) means any internet-facing instance is reachable by anonymous attackers. However, UI:R (user interaction required) and S:U (unchanged scope) cap the score - a victim must load the malicious payload for it to execute. The CVSS temporal modifiers reinforce this: E:P confirms a POC exists, RL:X indicates no remediation level has been defined (consistent with the absence of a vendor patch), and RC:R reflects reasonable but not fully confirmed information. No EPSS score was provided in the input data, so exploitation probability cannot be quantified; however, the combination of stored XSS, public POC, and an unpatched small-vendor PHP application targeting hospitality operators warrants treatment above the raw CVSS score suggests for organizations running this software. This is not a generic high-CVSS-but-low-real-risk issue - the public exploit lowers attacker skill requirements significantly.

An attacker submits a JavaScript payload (e.g., a cookie-stealing script) into the name, email, people, or number reservation fields on the /ht/tour.php page of an unpatched installation. If the XSS is stored as indicated by the public POC repository, the payload persists in the application's backend and executes automatically in the browser of any hotel staff member or administrator who views the affected reservation record - enabling session token theft, credential harvesting via fake login overlays, or unauthorized actions performed under the victim's authenticated session. A working POC is publicly available at https://github.com/Xmyronn/Hotel-and-Tourism-Reservation-System---Stored-XSS.git, substantially lowering attacker skill requirements.