CVE-2026-108613 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the AiragAppController release handler that allows any authenticated user to publish or unpublish other users' AI applications. Low-privileged attackers can send POST requests to /airag/app/release to obtain share tokens exposing applications to anonymous chat access, or invalidate existing share links.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in server-side access control mechanisms within the AiragAppController module. Specifically, the release handler endpoint responsible for managing the publication status of AI applications lacks proper authorization checks to verify that the authenticated user initiating the request is the legitimate owner or an authorized administrator of the target application. This architectural flaw allows any validly authenticated user, regardless of their privilege level, to manipulate the state of other users' resources by sending HTTP POST requests to the /airag/app/release endpoint. The absence of object-level permission validation means that the system trusts the identity provided in the session or token without verifying if that identity has the requisite rights over the specific resource identifier included in the request payload.
From a technical perspective, this flaw is classified as an Insecure Direct Object Reference (IDOR) combined with Broken Access Control. Attackers can exploit this by crafting malicious requests where they substitute the application ID of another user into their own API calls. By doing so, low-privileged attackers gain the ability to publish applications that are intended to be private or restricted, thereby generating share tokens that expose sensitive AI models and associated data to anonymous chat access. Conversely, attackers can also unpublish legitimate applications belonging to other users, effectively causing a denial of service for those application owners by invalidating existing share links and disrupting ongoing user interactions with the platform.
The operational impact of this vulnerability is significant in multi-tenant or collaborative environments where JeecgBoot is deployed as an AI development framework. The ability to publish others' applications exposes proprietary algorithms, training data, and configuration details to unauthorized parties who can interact with them via public share links. This leads to potential intellectual property theft and privacy violations for the application owners. Furthermore, the capability to unpublish other users' applications disrupts business continuity and service availability, as legitimate end-users lose access to tools they rely on. In scenarios where these AI applications process sensitive personal or corporate data, this exposure could lead to severe regulatory compliance issues under frameworks such as GDPR or HIPAA if protected health information or personally identifiable information is exposed through the public endpoints.
This vulnerability aligns with CWE-284: Improper Access Control and CWE-639: Authorization Bypass Through User-Controlled Key from the Common Weakness Enumeration database. In terms of offensive security tactics, it maps to MITRE ATT&CK technique T1078: Valid Accounts, as exploitation requires initial authentication but leverages that access for unauthorized actions, and potentially T1496: Host-Based Configuration Manipulation if the published applications alter system behavior or expose internal configurations. To mitigate this risk, developers must implement strict object-level authorization checks within the AiragAppController release handler to ensure that only the owner of an AI application can modify its publication status. This involves validating the user ID associated with the active session against the ownership field of the target application record before processing any state change requests. Additionally, implementing role-based access control (RBAC) policies and conducting regular security audits on API endpoints are recommended practices to prevent similar authorization bypasses in future development cycles.