QloApps EUVD-2026-90438

Exploitation requires an authenticated QloApps back-office session (PR:L) and requires inducing an administrator to submit a crafted POST request to the room type editor's length-of-stay configuration (UI:P) - the malicious payload must be placed in the restriction_min_los or restriction_max_los parameters, which are rendered unescaped into input value attributes in admin/themes/default/template/controllers/products/lengthofstay.tpl. Limiting factors: this is reflected (not stored) XSS, so it requires per-attack social engineering of an authenticated admin rather than passive triggering; it affects only the administrative interface; and it is remediated in versions after 1.7.0 (PR #1899).

This is a genuinely low-to-moderate priority issue, not a false-high-CVSS alarm - the vendor-supplied CVSS 4.0 score of 5.1 is modest and realistic. The attack is network-reachable (AV:N) and low-complexity (AC:L), but exploitation is gated by two meaningful limiters: the attacker needs a low-privilege authenticated back-office context (PR:L) and must induce a legitimate administrator to submit a crafted POST (UI:P). Impact is limited to script execution in the victim's admin session with partial confidentiality/integrity and no availability loss (VC:L/VI:L/VA:N, SC:L/SI:L). No EPSS score, KEV listing, or public exploit code is provided in the input, so there is no evidence of active or automated exploitation - this signals targeted, opportunistic risk rather than mass exploitation. A HackMD write-up ('four reflected XSS QloApps') and a VulnCheck advisory are referenced, indicating detailed public technical documentation exists even though no weaponized exploit is cited. The source-code diff in PR #1899 confirms the root cause (unescaped restriction_min_los/restriction_max_los values rendered into input value attributes in lengthofstay.tpl), so the vulnerability and fix are well-corroborated.

An attacker with low-privilege back-office access (or who can craft a malicious link/form targeting the room type editor) induces an authenticated administrator to submit a POST to the length-of-stay configuration with a JavaScript payload in the restriction_min_los or restriction_max_los parameter. The unescaped value is reflected into an input element, executing arbitrary JavaScript in the administrator's session - enabling session actions such as CSRF-token theft or back-office account manipulation. No public exploit code is identified in the input, though a HackMD write-up and VulnCheck advisory document the technique.