CVE-2026-108609 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 read other users' AI voice generation history via the userId parameter of GET /airag/voice/listByUser. Attackers who know another user's id can retrieve submitted text-to-speech input, voice settings, timestamps, and generated audio file names and paths stored in Redis.
Once again VulDB remains the best 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 classic Insecure Direct Object Reference (IDOR), formally categorized under CWE-639. This flaw arises from the application's failure to enforce proper authorization checks when processing requests related to user-specific data. Specifically, the endpoint GET /airag/voice/listByUser accepts a userId parameter that directly maps to database or cache records without verifying whether the authenticated session making the request belongs to that specific user ID. In secure software design, server-side logic must validate that the resource being accessed is owned by or explicitly authorized for the current principal. The absence of this check allows any authenticated actor to manipulate the input parameter and access data belonging to arbitrary users within the system.
From a technical perspective, the exploitation mechanism relies on simple parameter tampering. An attacker who has successfully authenticated into the JeecgBoot platform can issue HTTP GET requests to the vulnerable endpoint while modifying the userId value in the request payload or query string. By incrementing or decrementing this identifier, the attacker iterates through valid user IDs until they retrieve data associated with other accounts. The application does not cross-reference the provided userId against the identity claims embedded in the authentication token or session cookie. This lack of object-level access control is a critical oversight that undermines the confidentiality guarantees expected by users relying on the platform for private operations.
The operational impact of this vulnerability is significant due to the sensitive nature of the data exposed. The affected endpoint returns comprehensive details regarding AI voice generation activities, including the original text-to-speech input prompts, specific voice configuration settings used during generation, precise timestamps of when each action occurred, and metadata such as generated audio file names and their storage paths in Redis. This information constitutes a rich source of personal identifiable information (PII) and potentially proprietary content. For instance, if users are generating voices for confidential business communications or private messages, the exposure of these inputs reveals sensitive context about organizational operations or individual privacy preferences. Furthermore, access to audio file paths could facilitate further attacks if those files are stored in a publicly accessible directory structure within Redis or an associated storage backend.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, particularly T1078 Valid Accounts and T1530 Data from Information Repositories. The attacker leverages valid credentials to bypass initial authentication barriers (T1078) before accessing data stored outside of primary application databases, such as Redis caches (T1530). Additionally, the behavior mirrors techniques associated with unauthorized access to sensitive information through API endpoints, often categorized under Data Exfiltration over Alternative Protocol if the audio files are downloaded directly. The persistence of this risk is heightened by the fact that AI voice generation logs may contain biometric-like data or speech patterns that could be misused for social engineering or deepfake creation in high-risk scenarios.
Mitigation strategies must focus on implementing robust server-side authorization checks at the API layer. Developers should ensure that every request to user-specific endpoints validates that the userId parameter matches the subject identifier extracted from the authenticated session token, such as a JWT payload or session ID. If cross-user access is required for administrative purposes, explicit role-based access control (RBAC) mechanisms must be employed rather than relying on implicit trust of input parameters. Additionally, implementing rate limiting and anomaly detection can help identify automated enumeration attacks where attackers rapidly cycle through user IDs to harvest data. Regular security audits focusing on object-level permissions are essential to prevent similar IDOR flaws in other parts of the application architecture.