CVE-2026-108608 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 voice records by supplying an arbitrary userId to DELETE /airag/voice/deleteVoiceRecord. Attackers can obtain record ids from the unchecked GET /airag/voice/listByUser endpoint and delete victims' text-to-speech history entries stored in Redis, one per request.
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 classic Insecure Direct Object Reference (IDOR), formally categorized under CWE-639. This flaw arises from the application's failure to properly validate whether an authenticated user has authorization to perform actions on specific resources, specifically AI voice records stored within the system. The core technical deficiency lies in the DELETE endpoint located at /airag/voice/deleteVoiceRecord, which accepts a userId parameter without verifying that this identifier corresponds to the currently logged-in session or is explicitly permitted for deletion by the requesting user. Consequently, an attacker who has successfully authenticated to the application can manipulate this parameter to target arbitrary users within the system.
The operational exploitation of this vulnerability relies on the availability of valid resource identifiers. The GET endpoint /airag/voice/listByUser serves as a critical information disclosure vector because it allows any authenticated user to retrieve lists of voice records associated with various userIds without adequate access controls. By enumerating these record IDs, an attacker can construct targeted DELETE requests against the vulnerable endpoint. Each request targets a specific text-to-speech history entry stored in Redis, allowing for precise and granular deletion of victim data on a one-per-request basis. This mechanism enables attackers to systematically erase sensitive audio processing logs belonging to other users, effectively causing a denial of service for those individuals regarding their historical voice interactions while potentially obscuring audit trails or forensic evidence related to prior activities.
From an impact perspective, this vulnerability compromises the integrity and availability aspects of the CIA triad for affected user accounts. While it does not directly lead to unauthorized access or data exfiltration in its current form, the ability to delete critical operational records undermines trust in the system's reliability and can disrupt workflows that depend on historical voice data retention. Furthermore, if these logs are used for compliance auditing or security monitoring, their deletion could hinder incident response capabilities by removing evidence of past interactions. The reliance on Redis for storage implies that this is an ephemeral store, meaning the loss of records may be permanent unless external backups exist, exacerbating the impact of each successful delete operation.
To mitigate this vulnerability, developers must implement strict object-level authorization checks within the business logic handling the DELETE request. This involves ensuring that the userId parameter in the request body or query string matches the authenticated user's identity or is explicitly authorized by an administrative role with permission to manage other users' data. Access control mechanisms should be enforced at both the service layer and, ideally, through framework-level security annotations such as @PreAuthorize in Spring Security contexts. Additionally, input validation should verify that the referenced resource actually exists and belongs to a permissible scope before processing the deletion command. For existing deployments, upgrading to a patched version of JeecgBoot is essential. In the interim, network-level controls or Web Application Firewall rules can be configured to restrict access to sensitive endpoints based on user roles, although this is less effective than fixing the underlying code logic. Monitoring logs for unusual patterns of DELETE requests against varying userIds may also aid in detecting active exploitation attempts.