CVE-2026-110107 in RuoYi-Cloud-Plus
Summary
by MITRE • 10/13/2026
RuoYi-Cloud-Plus through 6.0.0 contains an insecure direct object reference vulnerability that allows authenticated users to delete other users' social login bindings by supplying their socialId. Attackers can send DELETE /auth/unlock/{socialId}, which deletes sys_social rows by primary key without ownership checks, removing victims' OAuth tokens and blocking social login.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The RuoYi-Cloud-Plus framework, specifically through version 6.0.0, contains a critical insecure direct object reference vulnerability within its authentication module. This flaw stems from the implementation of the user account unlock functionality via an HTTP DELETE endpoint that accepts a social identifier as a path parameter. The underlying database operation targets the sys_social table, which stores credentials and metadata for third-party OAuth integrations such as WeChat, QQ, or GitHub logins. When a request is made to delete/unlock a specific social binding using its unique ID, the application logic retrieves the record based solely on this identifier without verifying whether the authenticated user initiating the request owns that particular account linkage. This lack of authorization checks allows any validly authenticated user to manipulate resources belonging to other users by simply guessing or enumerating target social IDs.
From a technical perspective, the vulnerability represents a classic case of broken access control where the server trusts client-supplied identifiers without performing necessary ownership validation. The API endpoint DELETE /auth/unlock/{socialId} is designed to remove a specific OAuth binding from the system database. However, because the backend does not cross-reference the social ID with the identity token or session context of the requesting user, it treats all delete requests as valid regardless of their origin. This architectural oversight means that an attacker who has obtained credentials for any low-privilege account can target high-value accounts by supplying the corresponding socialId in the request path. The database executes a direct deletion based on the primary key, effectively stripping the victim's connection to their external identity provider without triggering any security alerts or requiring additional proof of ownership such as password confirmation or multi-factor authentication steps.
The operational impact of this vulnerability is severe for organizations relying on RuoYi-Cloud-Plus for user management and single sign-on capabilities. By deleting a victim's social login binding, an attacker effectively locks the victim out of their account if that method was their primary means of access. This action disrupts business continuity by preventing legitimate users from logging in through familiar channels like corporate SSO or consumer OAuth providers. Furthermore, this vulnerability can be leveraged as part of a broader attack chain to facilitate account takeover. If an attacker also possesses the victim's email address associated with the social login, they might exploit password reset mechanisms that rely on verifying ownership via those same external accounts. By removing the binding first, the attacker ensures that even if a password change is attempted, the verification step fails or can be manipulated, potentially allowing the attacker to set a new password and seize control of the account entirely.
This vulnerability aligns with CWE-639, which categorizes issues related to authorization bypasses through direct object references where access controls are not enforced on specific data objects. It also maps directly to MITRE ATT&CK technique T1078, specifically Valid Accounts, as it requires initial authentication but exploits the lack of proper privilege separation between users. To mitigate this risk, developers must implement strict ownership verification logic before executing any destructive operations like deletion or modification of user-related records. The application should validate that the socialId provided in the request belongs to the authenticated user by querying the database with both the user ID and the social identifier as conditions for the delete operation. Additionally, implementing rate limiting on authentication endpoints can help mitigate brute-force attempts if attackers attempt to enumerate valid social IDs. Regular security audits focusing on access control lists and object-level permissions are essential to prevent similar flaws in future updates of the framework.