CVE-2026-116745 in QloApps
Summary
by MITRE • 10/27/2026
QloApps through 1.7.0 contains an information disclosure vulnerability in OrderConfirmationController::init() that allows unauthenticated attackers to obtain guest order references and emails by supplying guest id_cart values. Attackers can iterate sequential id_cart values, read the Location redirect header, view booking details via guest-tracking, and convert guests into accounts with attacker-chosen passwords.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in QloApps versions through 1.7.0 represents a critical information disclosure flaw located within the OrderConfirmationController::init() method. This security defect stems from insufficient access controls on endpoints designed to handle guest order confirmations and tracking. Specifically, the application fails to adequately validate whether the requesting user has legitimate authorization to view or interact with specific shopping cart data based on the provided id_cart parameter. Because this validation is missing or flawed, unauthenticated attackers can exploit this weakness by supplying arbitrary or sequential id_cart values to retrieve sensitive information associated with guest orders that they do not own.
The operational impact of this vulnerability is significant as it allows for the systematic enumeration and extraction of personally identifiable information (PII). By iterating through sequential cart identifiers, an attacker can harvest a comprehensive list of guest order references and email addresses. This process effectively turns what should be private transactional data into publicly accessible information. The ability to view booking details via the guest-tracking feature further exacerbates the risk, as it exposes specific service or product reservations linked to these compromised accounts. Such exposure not only violates user privacy but also facilitates targeted phishing attacks where attackers can craft highly convincing messages using real order details and recipient email addresses obtained through this enumeration process.
Beyond simple data leakage, this vulnerability enables a more severe account takeover scenario. The flaw allows an attacker to convert guest orders into full customer accounts by assigning attacker-chosen passwords. This capability effectively grants the adversary control over existing user profiles without needing to know the original credentials or trigger standard password reset mechanisms that might alert the legitimate owner. By assuming ownership of these accounts, attackers can access order history, modify personal details, and potentially exploit any loyalty points or credits associated with the compromised guest identities. This transforms a simple information disclosure into a full authentication bypass and identity theft vector.
From a classification perspective, this vulnerability aligns closely with CWE-200: Information Exposure, as it involves the unintended leakage of sensitive data to unauthorized parties. Furthermore, the exploitation technique of iterating through sequential identifiers to discover valid resources is characteristic of CWE-284: Improper Access Control. In terms of offensive security frameworks, such behavior maps to ATT&CK techniques related to Discovery and Collection, specifically leveraging API endpoints for reconnaissance and subsequent Account Manipulation or Credential Stuffing depending on how the converted accounts are utilized. The lack of proper authorization checks in the controller logic is a fundamental design flaw that undermines the integrity of the application's user isolation mechanisms.
Mitigation strategies must focus on implementing robust access control measures within the OrderConfirmationController::init() method and related endpoints. Developers should enforce strict ownership verification, ensuring that only users who legitimately own the shopping cart or order can retrieve its details. This involves validating session tokens or authentication states against the resource being accessed rather than relying solely on the presence of an id_cart parameter in the request payload. Additionally, implementing rate limiting and CAPTCHA challenges can help mitigate automated enumeration attacks by detecting and blocking rapid sequential requests from a single source IP address.
To further secure the application, it is advisable to randomize or obfuscate internal identifiers such as cart IDs so that they cannot be easily guessed through simple iteration. Implementing comprehensive logging and monitoring for unusual access patterns will also aid in early detection of exploitation attempts. Regular security audits focusing on authorization logic across all public-facing controllers are essential to prevent similar vulnerabilities from persisting in the codebase. Ensuring that guest tracking features require some form of proof-of-ownership, such as a unique token sent via email or requiring partial order reference validation alongside other credentials, would significantly reduce the attack surface and protect user data integrity.