QloApps CVE-2026-75498

Exploitation requires valid QloApps back-office administrator credentials, confirmed by PR:H in the CVSS 4.0 vector. The attacker must have network access to the back-office (admin panel) web interface, which is typically exposed over HTTP/HTTPS. The primary vulnerable entry point is the 'bo_query' parameter passed to 'searchByName()' in 'Address.php'; the back-office address search feature must be reachable. Additional vulnerable code paths exist in the customer message search and hotel reservation module functionality (refund rules, feature pricing, demand advance options). Exploitation is strictly limited by the administrative authentication barrier - unauthenticated or low-privilege users cannot reach the affected parameters. Restricting the admin panel to an internal network or VPN eliminates the network-based attack vector entirely.

The CVSS 4.0 score of 8.6 reflects genuinely high impact against the vulnerable system (VC:H/VI:H/VA:H) once the attack succeeds, but the PR:H metric - requiring full back-office administrator credentials - is the dominant limiting factor in real-world exploitability. This makes the vulnerability a post-compromise escalation path or an insider-threat vector rather than an initial-access risk. Attack complexity is low (AC:L, AT:N), so the SQL injection itself is trivial to execute once credentials are in hand. No CISA KEV listing and no known public exploit code reduce urgency relative to unauthenticated issues of similar severity; EPSS data was not supplied in the available intelligence, so numeric exploitation probability cannot be assessed. The realistic threat model is narrow: credential compromise via phishing or credential stuffing targeting QloApps administrators, or a malicious insider. Organizations that isolate the back-office panel behind a VPN or IP allowlist significantly reduce exposure beyond the authentication requirement alone.

An attacker who has obtained valid QloApps back-office administrator credentials - via phishing, credential stuffing against a reused password, or insider access - authenticates to the admin panel and submits a crafted value in the 'bo_query' parameter that escapes the SQL LIKE clause and appends additional SQL statements. Because no input sanitization is applied before query execution, the attacker can enumerate the full database schema, extract sensitive guest reservation and payment records, or modify data. No public proof-of-concept has been identified at time of analysis, but the raw string concatenation pattern visible in the patch diff makes manual exploitation straightforward for any attacker with SQL injection knowledge.