CVE-2026-111630 in abp-next-admin
Summary
by MITRE • 10/16/2026
abp-next-admin 10.2.0 through 10.6.0 contains an insecure direct object reference vulnerability in the LINGYUN.Abp.AIManagement module that allows authenticated users to access other users' AI chat conversations by supplying their ConversationId. Attackers holding the Chat permission can call ChatAppService.GetListAsync or SendMessageAsync with a victim's ConversationId GUID to read chat messages and inject messages into that conversation.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in abp-next-admin versions 10.2.0 through 10.6.0 represents a critical failure in access control mechanisms within the LINGYUN.Abp.AIManagement module, specifically classified as an Insecure Direct Object Reference or IDOR. This class of weakness occurs when an application exposes a reference to an internal implementation object, such as a database key or file name, without performing adequate authorization checks to ensure that the requesting user is permitted to access that specific resource. In this context, the system relies on the ConversationId GUID provided by the client to retrieve chat data but fails to verify whether the authenticated user initiating the request owns that conversation or has explicit permission to view it. This architectural flaw allows any authenticated user with the Chat permission to bypass intended privacy boundaries and interact with conversations belonging to other users simply by manipulating the identifier parameter in API calls.
The technical exploitation of this vulnerability is straightforward due to the predictable nature of GUIDs and the lack of server-side ownership validation. An attacker can utilize standard HTTP methods to invoke two primary service endpoints: ChatAppService.GetListAsync and SendMessageAsync. By supplying a victim's ConversationId as an argument, the attacker can retrieve the complete history of messages within that private chat session via GetListAsync. Furthermore, the vulnerability extends beyond passive data exfiltration because the SendMessageAsync endpoint allows for active injection. This means an adversary does not merely read sensitive information but can also post malicious or misleading messages into another user's conversation thread, potentially leading to social engineering attacks, reputation damage, or further compromise if those conversations contain confidential business intelligence or personal credentials.
The operational impact of this vulnerability is severe, particularly in environments where abp-next-admin is used for enterprise applications handling sensitive communications. The ability to read other users' AI chat conversations constitutes a significant breach of confidentiality and data privacy regulations such as GDPR or HIPAA, depending on the nature of the data exchanged. Additionally, the capability to inject messages introduces integrity risks that can disrupt workflows, spread misinformation among team members, or trick victims into performing unauthorized actions based on fabricated instructions appearing in their legitimate chat interfaces. Since authentication is required but authorization checks are missing for specific resource ownership, even low-privilege users with basic Chat permissions pose a substantial threat to the security posture of the application and its user base.
To mitigate this vulnerability, developers must implement strict object-level access control mechanisms within the LINGYUN.Abp.AIManagement module. The primary remediation strategy involves modifying the backend logic for both GetListAsync and SendMessageAsync to validate that the authenticated session's user identifier matches the owner of the ConversationId being accessed. This can be achieved by joining the conversation table with a users or ownership mapping table during query execution, ensuring that only records belonging to the current user are returned or modified. Alternatively, implementing role-based access control policies that restrict these operations to specific administrative roles rather than general Chat permissions would reduce the attack surface if cross-user interaction is not a required feature. It is also advisable to implement rate limiting and logging for chat-related endpoints to detect anomalous patterns of conversation ID enumeration. Organizations running affected versions should immediately upgrade to a patched release or apply manual code fixes that enforce these ownership checks before exposing the application to untrusted networks.