CVE-2026-111648 in BuildAdmin
Summary
by MITRE • 10/16/2026
BuildAdmin through 2.3.9 contains an insecure direct object reference vulnerability that allows authenticated backend administrators to modify other administrators' profiles via the id parameter. Attackers holding the routine/adminInfo/edit permission can overwrite avatar, nickname, email, mobile and motto fields, including a super administrator's email and mobile.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The identified vulnerability represents an insecure direct object reference flaw within BuildAdmin versions up to 2.3.9, specifically affecting the backend administrative interface. This class of weakness occurs when an application uses user-supplied input to access objects directly without performing adequate authorization checks on whether that specific user is permitted to perform actions on the targeted resource. In this context, the vulnerability resides in the routine/adminInfo/edit endpoint, which processes requests containing an id parameter intended to identify the administrator profile being modified. The core technical failure lies in the application's logic, which accepts the provided identifier and proceeds with updating the corresponding database record without verifying that the authenticated session initiating the request belongs to the same entity as the target resource or possesses elevated privileges sufficient for cross-user modifications.
From a technical perspective, this flaw allows an attacker who has obtained valid credentials for any account possessing the routine/adminInfo/edit permission to manipulate data belonging to other administrators in the system. By simply altering the id parameter in HTTP requests sent to the edit endpoint, the attacker can target arbitrary administrator accounts regardless of their own identity within the application hierarchy. The scope of this manipulation is significant as it encompasses critical profile fields including avatar images, display nicknames, email addresses, mobile phone numbers, and personal mottoes. This capability effectively bypasses standard access control mechanisms that are typically designed to ensure users only interact with their own data profiles in user management systems.
The operational impact of this vulnerability extends beyond simple data corruption or privacy violations. Because the attacker can overwrite contact information such as email addresses and mobile numbers for other administrators, they gain a potent vector for account takeover attacks against higher-privileged accounts. For instance, by changing the super administrator's registered email address to one controlled by the attacker, subsequent password reset procedures would direct recovery links exclusively to the attacker's inbox. This sequence of events can lead to complete compromise of the highest privilege level within the application, granting unrestricted access to all backend functionalities and sensitive data stored therein. Such a scenario poses severe risks to organizational integrity, potentially leading to unauthorized data exfiltration, system defacement, or further lateral movement into connected network infrastructure depending on how BuildAdmin is integrated with other services.
This vulnerability aligns closely with CWE-639, which defines Insecure Direct Object References as the primary classification for this issue. The attack vector leverages ATT&CK technique T1078, specifically Valid Accounts and potentially T1098 if used to establish persistence through account modification. To mitigate this risk immediately, administrators should upgrade BuildAdmin to a version later than 2.3.9 where these access control checks have been corrected. In the interim, implementing strict server-side validation that ensures the id parameter in edit requests matches the user ID associated with the current authenticated session is essential. Additionally, enforcing role-based access controls that restrict profile modification capabilities strictly to super administrators or dedicated security roles can reduce the attack surface by limiting which accounts possess the routine/adminInfo/edit permission. Regular auditing of administrative actions and monitoring for anomalous changes to high-privilege account details will also aid in detecting potential exploitation attempts early.