CVE-2026-111705 in Fuint
Summary
by MITRE • 10/16/2026
Fuint through commit 57ec018 contains an insecure direct object reference vulnerability that allows authenticated members to read other members' booking records by supplying arbitrary bookId values to /clientApi/book/myBookDetail. Attackers can iterate the auto-increment bookId to retrieve contact names, mobile numbers, in-store verification codes, service dates, stores and remarks.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within Fuint through commit 57ec018 represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or IDOR. This flaw resides in the /clientApi/book/myBookDetail endpoint, which is designed to retrieve detailed information about a specific booking record for authenticated users. The core technical deficiency lies in the application's logic, which fails to validate whether the bookId parameter provided by the client corresponds to a resource owned by the currently authenticated user or one that they are explicitly authorized to access. Instead of enforcing proper ownership checks on the server side, the system blindly trusts the input value for bookId and returns the associated data if the record exists in the database. This lack of authorization verification allows any authenticated member to bypass intended security boundaries simply by manipulating the identifier passed in the request payload or URL parameters.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed through the booking details endpoint. By iterating through sequential auto-incrementing bookId values, an attacker can systematically enumerate and retrieve a comprehensive set of personally identifiable information belonging to other users. The compromised data includes contact names and mobile numbers, which facilitate further social engineering attacks or identity theft. Additionally, the exposure of in-store verification codes poses a direct risk to service integrity, as these codes are often used for authentication at physical locations or during check-in processes. Attackers can potentially use these stolen codes to impersonate legitimate users, gain unauthorized access to services, or disrupt business operations by canceling or altering bookings they do not own. The disclosure of specific service dates, store locations, and internal remarks further aids in profiling victims and understanding their habits, which could be leveraged for targeted phishing campaigns or physical security breaches.
From a classification perspective, this vulnerability aligns with CWE-639: Injection of Critical Data to an Unauthorized Actor via Insecure Direct Object Reference. It also maps directly to the MITRE ATT&CK framework under Technique T1078: Valid Accounts, as it requires authentication but exploits weak authorization controls rather than credential theft. The attack vector is classified as Local or Remote depending on network exposure, but typically falls under Accessing Resource Using Insecure Direct Object Reference (T1528) within the ATT&CK taxonomy for web applications. The simplicity of the exploitation method highlights a fundamental gap in the application's security architecture, where business logic does not enforce strict ownership constraints before processing sensitive data retrieval requests.
To mitigate this vulnerability, immediate remediation is required to implement robust authorization checks on the server side. Developers must modify the /clientApi/book/myBookDetail endpoint to verify that the bookId requested by the authenticated user actually belongs to them or a group they are authorized to manage. This can be achieved by joining the booking table with the users table in database queries and ensuring the userId matches the session token of the requester, rather than relying solely on the provided ID parameter. Additionally, implementing rate limiting on this endpoint is advisable to prevent rapid enumeration attacks using auto-incrementing IDs. Input validation should also enforce that bookId values are positive integers within expected ranges, although this alone does not solve the authorization flaw. Long-term solutions include adopting a security development lifecycle (SDL) approach with regular code reviews focused on access control logic and employing automated static application security testing tools configured to detect IDOR patterns in API endpoints.