QloApps EUVD-2026-110494

Requires a QloApps 1.6.0-1.7.0 installation with the qlohotelreview module active and its AddReview AJAX front-controller reachable. The specific prerequisites named in the evidence are: (1) the review_ajax_token is publicly exposed on storefront pages and can be reused, and (2) id_order values are sequential and guessable, allowing enumeration. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N), no authentication, no user interaction, and no special non-default configuration are required against a store running the review module. The limiting factor is impact scope only: the attacker can forge review content/ratings attributed to other orders (integrity), but cannot read order data or disrupt availability. The pre-patch code path confirmed by the fix diff shows the missing $objOrder->secure_key comparison as the sole gating weakness.

This is a genuine but low-to-moderate priority issue, and the signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) confirms remote, unauthenticated, low-complexity exploitation with no user interaction, which matches the description of an IDOR (CWE-639) reachable through a public AJAX token. However, impact is deliberately narrow: only VI:L (low integrity) is set, with VC:N and VA:N - there is no data disclosure and no availability loss. SSVC agrees: Exploitation=none (no observed exploitation), Automatable=yes (the attack is scriptable via sequential id_order enumeration), Technical Impact=partial. EPSS is low at 0.25% (16th percentile), and the vulnerability is NOT in CISA KEV, so there is no evidence of active exploitation - consistent with SSVC's 'none'. The vuln.today decision label is 'this_month', not 'act_now' or 'emergency', so this should be remediated on a routine monthly cycle rather than as a fire drill. Bottom line: a real, trivially automatable integrity/reputation flaw (fake reviews attributed to other customers), but one with limited technical impact and no confidentiality or availability consequences - appropriately rated medium (6.9), not a critical priority.

An unauthenticated attacker loads a QloApps storefront page, harvests the publicly exposed review_ajax_token, and scripts POST requests to the qlohotelreview AddReview action while incrementing id_order values. Because the AddReview handler never verified that the requester owned the order, each request posts a fake rating and review attributed to the real customer behind that order. No public exploit is identified in the input, but the VulnCheck advisory and the public fix diff (PR #1757) make the mechanism fully transparent and the attack straightforward to reproduce.