CVE-2026-115326: QloApps Authentication Bypass Vulnerability

CVE-2026-115326 Overview

CVE-2026-115326 is an Insecure Direct Object Reference (IDOR) vulnerability [CWE-639] in QloApps through version 1.7.0. The flaw resides in the OrderDetailController::displayAjaxSubmitRefundRequest() method. Authenticated customers can submit refund requests referencing service lines that belong to other customers. By pairing a foreign id_service_product_order_detail with their own id_order, attackers create refund records, cancel victims' service lines, and corrupt refund quantities on legitimate orders.

Critical Impact
Any authenticated customer can tamper with other customers' refund records and cancel their service lines, undermining order integrity across the booking platform.

Affected Products

QloApps through version 1.7.0
controllers/front/OrderDetailController.php (lines 624-631)
QloApps hotel booking and reservation deployments exposing the customer-facing order detail controller

Discovery Timeline

2026-10-22 - CVE-2026-115326 published to the National Vulnerability Database (NVD)
2026-10-22 - Last updated in NVD database

Technical Details for CVE-2026-115326

Vulnerability Analysis

QloApps exposes a front-end AJAX endpoint through OrderDetailController::displayAjaxSubmitRefundRequest() so customers can request refunds against service lines on their own bookings. The controller validates that the submitted id_order belongs to the authenticated customer but fails to verify that each submitted id_service_product_order_detail is actually linked to that order.

Because the service line identifier is trusted as supplied, an attacker can enumerate or guess id_service_product_order_detail values from other customers and attach them to a legitimate order they own. The controller then writes a refund record and updates service-line state against the foreign order. The result is cross-tenant tampering: victim service lines get canceled, refund quantities on legitimate orders are corrupted, and financial reconciliation data becomes unreliable.

Root Cause

The root cause is missing object-level authorization. The controller performs ownership checks on the parent order object but does not re-validate ownership of each child id_service_product_order_detail against the authenticated customer. This is the canonical pattern described in CWE-639: Authorization Bypass Through User-Controlled Key.

Attack Vector

Exploitation requires only low-privilege authentication (a standard customer account) and network access to the booking storefront. The attacker places or holds any valid order, then issues a refund submission swapping in a id_service_product_order_detail observed from another customer. No user interaction from the victim is required.

No public exploit code is provided in the realCodeExamples set for the vulnerable path itself. The upstream patch in commit 105241f and Pull Request #1930 hardens adjacent controller logic, including input escaping and uniqueness enforcement on administrative objects:

php

/**
 * Prevent creating a tab whose class name is already used.
 *
 * @return ObjectModel|false
 */
public function processSave()
{
    $className = trim((string) Tools::getValue('class_name'));
    $idExisting = Tab::getIdFromClassName($className);
    if ($idExisting && $idExisting != (int) $this->id_object) {
        $this->errors[] = Tools::displayError('A tab with this class name already exists.');
        return false;
    }

    return parent::processSave();
}

Source: QloApps Commit 105241f

Detection Methods for CVE-2026-115326

Indicators of Compromise

Refund records in the QloApps database where the id_customer on the refund does not match the owner of the referenced id_service_product_order_detail.
Service lines canceled or marked refunded without corresponding activity in the owning customer's session or order history.
Multiple refund submissions originating from a single customer session against disparate id_service_product_order_detail values.

Detection Strategies

Audit historical refund submissions and reconcile id_order ownership against each child id_service_product_order_detail ownership. Flag any mismatch.
Monitor web server access logs for repeated POST requests to the displayAjaxSubmitRefundRequest action, especially from accounts with low order counts.
Enable application-level logging for the OrderDetailController refund flow and alert when a single authenticated customer submits refunds spanning service identifiers outside their order history.

Monitoring Recommendations

Forward QloApps application and web server logs to a centralized analytics platform and build a rule for cross-customer id_service_product_order_detail references.
Add database-side triggers or scheduled integrity checks that fail builds when refund rows reference service lines from a different id_customer.
Alert finance operations on anomalous spikes in refund volume per account or per 24-hour window.

How to Mitigate CVE-2026-115326

Immediate Actions Required

Upgrade QloApps beyond version 1.7.0 once a release containing the authorization fix for OrderDetailController::displayAjaxSubmitRefundRequest() is available.
Review all refund records created on affected deployments and reverse any that reference service lines not owned by the submitting customer.
Restrict access to the customer refund endpoint to authenticated sessions only and rate-limit refund submissions per account.

Patch Information

Track remediation through the QloApps GitHub Repository and the referenced Vulncheck Advisory. The vulnerable code is anchored at OrderDetailController.php lines 624-631. Apply any upstream commit that enforces ownership validation on each id_service_product_order_detail before writing refund records.

Workarounds

Add a server-side check in displayAjaxSubmitRefundRequest() that joins each submitted id_service_product_order_detail to id_order and rejects the request when the pair is not owned by the authenticated id_customer.
Place a web application firewall (WAF) rule in front of the refund endpoint that validates request parameters against the authenticated session's known order identifiers.
Temporarily disable customer-initiated refund submissions and require staff to process refunds through the authenticated back-office until the patch is applied.

bash

# Example WAF-style guard: block refund submissions where id_service_product_order_detail
# cannot be resolved to the authenticated customer's orders.
SecRule REQUEST_URI "@contains displayAjaxSubmitRefundRequest" \
  "id:1026115326,phase:2,deny,status:403,\
   msg:'Blocked potential CVE-2026-115326 IDOR refund submission',\
   chain"
  SecRule ARGS:id_service_product_order_detail "@rx ^[0-9]+$" \
    "chain"
    SecRule &SESSION:verified_order_lines "@eq 0"