CVE-2026-108607 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains an insecure direct object reference vulnerability that allows authenticated users to delete other users' AI video generation records by supplying arbitrary userId values to DELETE /airag/video/deleteVideoRecord. Attackers can obtain record ids from the unchecked GET /airag/video/listByUser endpoint and delete victims' Redis-stored video history entries one record per request.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a classic Insecure Direct Object Reference, commonly categorized under CWE-639. This flaw arises from the application's failure to enforce proper authorization checks when processing requests that manipulate user-specific resources. Specifically, the API endpoint DELETE /airag/video/deleteVideoRecord accepts a userId parameter without verifying whether the authenticated session initiating the request possesses administrative privileges or ownership over the specified resource. Consequently, any authenticated user can arbitrarily supply different userId values in their HTTP DELETE requests to target and delete video generation records belonging to other users within the system.
The operational impact of this vulnerability is significant as it compromises the integrity and availability of data for multiple users without requiring privilege escalation beyond basic authentication. Attackers can leverage the unchecked GET /airag/video/listByUser endpoint to enumerate valid record identifiers associated with target victims. By combining these discovered record IDs with arbitrary userId values in subsequent DELETE requests, an attacker can systematically purge video history entries stored in Redis from the perspective of other users. This action effectively results in a denial of service for those affected individuals, as their AI-generated content and historical records are permanently removed or rendered inaccessible through unauthorized deletion operations.
From a technical standpoint, this vulnerability highlights a critical gap in server-side access control logic where object-level permissions are not validated against the identity of the requesting user. The reliance on client-supplied identifiers such as userId for determining resource ownership is inherently risky if not coupled with strict backend verification mechanisms that cross-reference these values against session tokens or database records associated with the current login context. This misalignment allows malicious actors to bypass intended security boundaries, treating sensitive data structures as publicly accessible resources modifiable by any valid credential holder rather than restricting access strictly to authorized owners or administrators.
To mitigate this vulnerability, developers must implement robust authorization checks within the DELETE /airag/video/deleteVideoRecord endpoint logic. The application should verify that the userId associated with the video record matches the authenticated user's identity retrieved from their session token or database profile before proceeding with any deletion operation. Additionally, implementing role-based access control can restrict such destructive actions to administrative users only if business requirements do not necessitate self-service data management for all users. Regular security audits and static code analysis focused on object reference validation patterns are recommended to prevent similar flaws in future development cycles. Aligning these fixes with OWASP API Security Top 10 guidelines, particularly regarding broken object level authorization, will ensure more resilient application architecture against unauthorized data manipulation attempts.