QloApps CVE-2026-75497

Exploitation requires a valid administrative account in the QloApps back-office - the CVSS vector PR:H confirms high-privilege authentication is mandatory. The attacker must have network access to the back-office admin panel (typically a /admin or /bo route). The vulnerable parameter (bo_query) is exposed through the customer message search functionality within the back-office UI. What limits exploitation: (1) administrative credentials must be compromised or held by the attacker; (2) the back-office is typically not exposed to the public internet in hardened deployments; (3) no default QloApps configuration automatically grants external parties admin access. Defenders should note that if admin panels are internet-accessible without IP restriction, the authentication barrier is the sole control preventing exploitation.

The CVSS 4.0 score of 8.6 with vector AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H accurately characterizes the theoretical impact, but PR:H (high privileges required) is the critical limiting factor for real-world risk. An attacker must already hold administrative credentials to the QloApps back-office before exploiting this flaw, which substantially narrows the realistic threat surface compared to unauthenticated SQL injection. The business impact upon successful exploitation is severe - full database read (hotel guest PII, reservation data, credentials) and write access. However, the requirement for administrative access means this is most relevant in insider-threat, credential-theft, or privilege-chaining scenarios rather than opportunistic mass exploitation. No EPSS score, KEV listing, or public exploit code was provided, and QloApps has a limited deployment footprint relative to mainstream platforms, further reducing aggregate exposure.

An attacker who has obtained administrative credentials to the QloApps back-office - through phishing, credential stuffing, or lateral movement - navigates to the customer message search interface and submits a crafted SQL fragment via the bo_query parameter (e.g., a UNION-based payload). The unsanitized value is concatenated directly into the SQL LIKE clause in CustomerMessage.php, enabling the attacker to enumerate all database tables, extract hotel guest PII and credentials, or modify reservation records. No public proof-of-concept has been identified, but the injection pattern is straightforward to exploit given the confirmed absence of parameterization.