CVE-2026-110216 in youlai-boot
Summary
by MITRE • 10/13/2026
youlai-boot through 2.21.1 contains a missing authorization vulnerability that allows any authenticated user to enable or disable accounts because the updateUserStatus handler lacks a @PreAuthorize check. Attackers can send PATCH requests to /api/v1/users/{userId}/status to disable root or admin accounts, locking administrators out, or re-enable accounts an administrator has disabled.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in youlai-boot versions up to 2.21.1 represents a critical failure in access control mechanisms within the application's user management module. Specifically, the flaw resides in the updateUserStatus handler, which is responsible for modifying the active or inactive status of user accounts via HTTP PATCH requests directed at the endpoint /api/v1/users/{userId}/status. The core technical deficiency is the absence of a @PreAuthorize annotation or equivalent server-side authorization check within this specific controller method. In typical Spring Boot applications utilizing Spring Security, such annotations are essential for enforcing role-based access control by verifying that the authenticated principal possesses the necessary administrative privileges before processing state-changing requests. Without this guardrail, the application relies implicitly on the fact that only administrators might know or guess the endpoint and user IDs, rather than enforcing a strict policy check at the code level. This design oversight effectively treats all authenticated users as having equal authority over account status modifications, regardless of their assigned roles or permissions within the system.
From an operational perspective, this missing authorization vulnerability allows any authenticated user to perform actions that should be restricted exclusively to administrators with elevated privileges. The most severe impact involves the ability to disable root or administrator accounts by sending a PATCH request with a payload indicating deactivation for those specific userIds. This action can lead to a complete denial of service for administrative functions, effectively locking legitimate system owners out of their own infrastructure. Once an admin account is disabled through this vector, recovery may require direct database manipulation or backend file access if no other active administrator accounts exist, significantly increasing the complexity and risk associated with incident response. Furthermore, attackers can re-enable user accounts that have been deliberately disabled by administrators for security reasons, such as when a compromised credential is suspected but not yet revoked, thereby undermining the organization's ability to contain threats through account suspension.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically highlighting failures where authorization checks are omitted or incorrectly implemented in critical business logic functions. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation requires valid authentication credentials but abuses them to perform unauthorized administrative actions. The attack vector is classified under Remote Code Execution implications regarding system integrity and availability, though technically it falls under Privilege Escalation or Authorization Bypass categories depending on whether the attacker gains control over an account they did not own or simply disrupts service by disabling admins. In modern web application security frameworks, this type of flaw is often referred to as a Broken Access Control vulnerability, which consistently ranks at the top of the OWASP Top Ten list due to its prevalence and potential for catastrophic impact on data confidentiality and system availability.
To mitigate this risk, immediate remediation should focus on implementing robust server-side authorization checks within the updateUserStatus handler. Developers must ensure that every endpoint performing state-changing operations validates the current user's role against a predefined policy requiring administrative privileges before proceeding with database updates. This can be achieved by adding appropriate @PreAuthorize annotations or custom security interceptors that verify if the requesting user has the ADMIN role and is not attempting to modify their own status unless explicitly permitted, while strictly prohibiting modification of other admin accounts without multi-factor approval in high-security environments. Additionally, implementing an audit log for all account status changes can aid in detecting such abuse attempts post-exploitation. Regular security code reviews focusing on access control logic are essential to prevent similar oversights in future development cycles, ensuring that privilege boundaries are strictly enforced at the application layer rather than relying on client-side restrictions or implicit trust assumptions.