QloApps EUVD-2026-110493

No special conditions - remote unauthenticated exploitation against default QloApps installations through 1.7.0, because the pre-patch OrderConfirmationController::init() built the guest redirect without validating the order's secure_key (the fix adds Validate::isLoadedObject($order) and hash_equals on secure_key). LIMITING FACTORS: only guest-created orders (guest carts) are exposed - registered-customer orders follow the history flow and are unaffected; the attacker must supply/enumerate id_cart values that actually map to guest carts, and the disclosed data is limited to order references, emails, and booking details plus the guest-to-account conversion. No authentication, no user interaction, and no non-default configuration are required.

The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N) scores 6.9 (Medium): remotely reachable, low attack complexity, no authentication, no user interaction, with low confidentiality and low integrity impact and no availability impact. Signals are largely consistent rather than conflicting: the flaw is unauthenticated and trivially automatable (sequential id_cart enumeration), which argues for real-world practicality, yet EPSS is only 0.23% (13th percentile) and the issue is NOT in CISA KEV, indicating no observed widespread or active exploitation. The vuln.today decision label is 'this_month', not act_now/emergency, matching a genuine-but-bounded priority. The impact ceiling is the key moderating factor: disclosure is limited to guest order references and associated emails plus a guest-to-account conversion, not full system or admin compromise - this is why both VC and VI are rated Low rather than High. Net: a legitimate, patch-this-month authorization flaw (CWE-639 IDOR) rather than a drop-everything emergency, but the unauthenticated + automatable nature means it should not be deprioritized to 'low real risk' either.

An unauthenticated attacker scripts requests to OrderConfirmationController while incrementing sequential id_cart values that correspond to guest carts, reading the returned Location redirect header to harvest guest order references and the associated customer emails. Using the guest-tracking flow the attacker then views booking details and can convert the guest into a registered account with an attacker-chosen password. No public exploit code is identified at time of analysis, though the VulnCheck advisory documents the technique step-by-step; the CVSS AV:N/AC:L/PR:N/UI:N profile confirms the attack needs only network access and no credentials or victim interaction.