Description

QloApps through 1.7.0 contains an authorization bypass vulnerability in AdminProductsController::ajaxProcessBulkUpdateRooms that allows hotel-restricted back-office employees to modify rooms of other hotels. Attackers can submit foreign room IDs in the id_rooms parameter to change status, floor, comments, or inactive dates, disrupting availability and bookings.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-10-06T13:16:46.913Z",
  "pubdate": "2026-10-06T13:16:46.913Z",
  "executiveSummary": "QloApps versions up to 1.7.0 are susceptible to an authorization bypass vulnerability located within the backend administrative interface.\nThe vulnerability resides in the AdminProductsController::ajaxProcessBulkUpdateRooms function, which fails to enforce strict multi-tenant boundary checks for restricted back-office user accounts.\nBy manipulating the id_rooms parameter, an authenticated attacker with hotel-restricted administrative privileges can perform unauthorized modification of room data belonging to other hotels managed within the same installation.\nThis flaw effectively permits unauthorized cross-tenant resource manipulation, allowing a malicious actor to alter critical room metadata including status, floor location, administrative comments, and inactive date configurations.\nThe exploitation of this vulnerability leads to significant operational impact, enabling the disruption of room availability, the corruption of booking management records, and potential financial implications for hotel owners.\nSuccessful exploitation requires the attacker to hold legitimate, albeit restricted, back-office access to the QloApps platform. No further authentication bypass is required beyond the existing session, but the application fails to validate if the requested room IDs fall within the scope of the authenticated administrator's managed properties.",
  "technicalDetails": "The root cause of this vulnerability is an Insecure Direct Object Reference (IDOR) pattern stemming from insufficient authorization validation in the AdminProductsController::ajaxProcessBulkUpdateRooms function within the QloApps back-office module.\nThe application relies on administrative session tokens to provide access to management features. However, the specific function responsible for bulk updating room records does not implement server-side verification to confirm that the room IDs submitted via the POST parameter 'id_rooms' are associated with the hotel assigned to the currently authenticated administrative user.\nWhen an attacker triggers a bulk update request, the controller logic processes the incoming payload without correlating the requested room IDs against the permissions assigned to the session owner's profile. This allows a restricted administrator, who is authorized only for a subset of the platform's inventory, to submit foreign room IDs that belong to other hotels.\nThe attack flow proceeds as follows: First, the attacker identifies valid room IDs belonging to other hotels through enumeration or observation of the platform's inventory management endpoints. Second, the attacker initiates a bulk update operation via the AdminProductsController. Third, the attacker injects the unauthorized foreign IDs into the 'id_rooms' parameter of the HTTP POST request. Finally, the server-side logic processes these identifiers and applies the requested state changes—such as setting rooms to 'inactive' or modifying floor designations—to the external room records.\nBecause the function lacks strict input sanitization regarding scope, the database abstraction layer executes update queries on arbitrary records defined by the input, bypassing the multi-tenant isolation mechanisms intended for restricted back-office staff. The post-exploitation impact includes the arbitrary modification of availability, leading to forced cancellations or booking errors, which directly affects the integrity of the hotel management system. The vulnerability remains present in versions 1.7.0 and earlier, necessitating rigorous access control enforcement at the controller level to ensure that all administrative actions are constrained to authorized inventory objects."
}