QloApps EUVD-2026-99013

Requires a valid, authenticated back-office employee account that is intentionally restricted to a subset of hotels, AND a multi-hotel QloApps deployment where cross-hotel data isolation is expected - in a single-hotel install there is no foreign data to reach. The specific weakness is that OrderSlip::getSlipsIdByDate() and AdminSlipController's query apply only the PrestaShop shop restriction and omit the HotelBranchInformation hotel restriction, so credit slips are not scoped to the employee's assigned hotel(s). Limiting factors: attacker must already possess low-privilege back-office credentials with credit-slip access (no anonymous/network-only path), and the exposure is confined to credit-slip/refund data and voucher generation.

This is a moderate, authorization-layer risk rather than a critical one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N, base 5.3) is self-consistent with the description: exploitation requires an already-authenticated low-privilege back-office employee account (PR:L), so this is a horizontal privilege-escalation / broken-access-control issue (CWE-862), not a pre-auth or network-anonymous flaw. No EPSS score, no CISA KEV listing, and no confirmed public exploit code are present in the input, so there is no evidence of active or at-scale exploitation; the signals are consistent in pointing to low real-world urgency. Impact is limited to Low confidentiality (exposure of other hotels' customer identities and refund amounts) and Low integrity (marking slips redeemed and minting store-credit vouchers) - the voucher-generation capability gives it a financial-fraud dimension that raises its practical seriousness above a pure info-leak, but it still demands an insider/trusted-employee foothold. Net: a legitimate multi-tenant isolation bug worth patching in affected multi-hotel deployments, but not an emergency given the authenticated prerequisite and absence of exploitation signals.

A back-office employee at a multi-hotel QloApps property, whose account is scoped to only their own hotel, browses to the AdminSlipController credit-slips page and finds refund records belonging to other hotels are not filtered out. They list and export other hotels' credit slips as PDF (harvesting customer names and refund amounts) and mint store-credit vouchers against those foreign refund records. No public exploit code is identified at time of analysis, though a researcher writeup (hackmd.io) and the vendor fix commit document the flaw.