CVE-2026-108878 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the AiragAppController queryById handler that allows low-privileged authenticated users to read any AI application configuration. Attackers can enumerate application ids via the unguarded /airag/app/listDict endpoint and query each id to obtain system prompts, memory prompts, model ids, knowledge base ids, and plugin bindings of other users' applications.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms within the AiragAppController module. Specifically, the queryById handler lacks proper authorization checks for authenticated users with low privileges. This architectural flaw allows any authenticated user, regardless of their role or permission level, to retrieve sensitive configuration data belonging to other applications by manipulating the unique identifier passed to this endpoint. The core technical issue lies in the absence of a verification step that ensures the requesting user is the owner of the application being queried or possesses administrative rights over it. Consequently, the system treats all requests to fetch application details as valid if they contain a syntactically correct ID, ignoring the contextual relationship between the user session and the target resource.
The operational impact of this vulnerability is severe due to the nature of the data exposed. AI applications configured within JeecgBoot often encapsulate highly sensitive information including system prompts, memory contexts, model identifiers, knowledge base references, and plugin bindings. System prompts define the behavior and constraints of large language models, while memory prompts may contain historical context or user-specific instructions that could reveal proprietary logic or personal data. Model IDs point to specific AI engines which might have associated costs or security profiles, and knowledge base IDs can lead to internal documents containing intellectual property or confidential business information. Plugin bindings expose the integration points with external services, potentially revealing API keys or endpoint configurations if not properly secured elsewhere in the stack.
Attackers can exploit this vulnerability through a two-step enumeration process facilitated by an unguarded endpoint. The /airag/app/listDict endpoint does not enforce authorization checks, allowing attackers to retrieve a list of application identifiers associated with various users or systems within the environment. Once these IDs are obtained, they can be iteratively submitted to the vulnerable queryById handler. This combination effectively turns a simple IDOR (Insecure Direct Object Reference) flaw into a comprehensive data exfiltration vector. The attacker does not need prior knowledge of specific target applications; instead, they can systematically harvest configuration details from all accessible application IDs in the system database.
From a classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, specifically falling under the sub-category of IDOR where object references are used without sufficient validation against user permissions. In terms of offensive security tactics, this behavior maps to ATT&CK technique T1078, Valid Accounts, as it relies on legitimate authentication credentials but abuses their privileges through misconfigured access controls. It also relates to T1530, Data from Cloud Storage Objects, if the AI configurations are stored in a manner that treats them as accessible objects without proper isolation boundaries. The exploitation does not require complex injection techniques or buffer overflows; it relies purely on logical flaws in the application layer's security design.
Mitigation strategies must focus on implementing robust authorization checks within the AiragAppController queryById method. Developers should ensure that every request to retrieve application details verifies that the authenticated user is either the owner of the specific AI application or holds a role with explicit permission to view such configurations for other users. This can be achieved by integrating middleware or service-layer validation that cross-references the requested resource ID against the current session's ownership records before returning any data. Additionally, restricting access to the /airag/app/listDict endpoint is crucial to prevent easy enumeration of target IDs. Implementing rate limiting and logging on these endpoints will also aid in detecting automated scanning attempts by malicious actors seeking to exploit this weakness.