QloApps EUVD-2026-99011

Exploitation requires an authenticated back-office employee account whose profile is restricted to one or more specific hotels (PR:L) - this is the central prerequisite, so it is not exploitable by anonymous external users. The attacker must reach the room-type creation workflow in AdminProductsController, where the hotel selector in the product/information form (informations.tpl) is populated via the unfiltered hotelsNameAndId() method rather than a profile-scoped lookup, exposing all id_hotel values. The flaw affects default installations of QloApps up to and including 1.7.0 with no special configuration needed; the primary limiting factors are the need for valid low-privilege credentials and the requirement that the instance host multiple hotels for cross-tenant impact to be meaningful. No user interaction from a victim is required (UI:N).

This is a genuine but moderate-severity authorization flaw, best treated as a medium-priority fix rather than an emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 MEDIUM score are internally consistent with the description: exploitation is network-reachable and low-complexity but requires an authenticated, already-provisioned back-office employee account (PR:L), which materially limits the attacker population to insiders or anyone who has compromised a hotel-restricted staff account. Impact is bounded - VC:L/VI:L with VA:N - reflecting cross-tenant data enumeration and the ability to create (not destroy) room types and inventory under hotels the employee should not control; there is no availability impact and no cross-system scope change (SC:N/SI:N). No EPSS score, CISA KEV entry, or explicit POC flag is present in the input, so there is no signal of active or widespread exploitation; however, a detailed third-party technical writeup (hackmd.io/@leediay) and a VulnCheck advisory exist, meaning the exploitation method is publicly documented even if no weaponized exploit is confirmed. The signals do not conflict: a moderate CVSS, absent exploitation telemetry, a niche product, and an available vendor patch all point to routine remediation. The main caveat is that this is a multi-tenant/SaaS-style weakness, so real risk rises sharply for operators who host many independent hotels under one QloApps instance.

A hotel-restricted back-office employee (or an attacker who has phished/compromised such an account) opens the room-type creation form, where an unfiltered hotel selector exposes the IDs of every hotel in the installation. The attacker submits a POST to AdminProductsController with a foreign id_hotel value, causing room types and inventory to be created under a hotel they were never assigned to. No special exploit code is required beyond manipulating the form parameter, and a public technical writeup documents the exact steps.