CVE-2026-108654 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the OssFileController queryById handler that allows low-privileged authenticated users to read object storage file records. Attackers who know a record id can request GET /sys/oss/file/queryById to obtain original file names and direct storage URLs of files uploaded by other users.
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 critical failure in access control mechanisms, specifically classified under CWE-284 as Improper Access Control. This flaw resides within the OssFileController component, which is responsible for managing object storage file operations. The specific point of exploitation is the queryById handler method, designed to retrieve metadata and details about individual files stored in the system's backend infrastructure. In a properly secured application architecture, such endpoints must enforce strict authorization checks that verify whether the requesting user has permission to access the specific resource identified by the provided identifier. However, in this instance, the framework fails to validate the relationship between the authenticated session of the requester and the ownership or visibility scope of the target file record.
This technical deficiency allows low-privileged authenticated users to bypass intended security boundaries with minimal effort. An attacker who has successfully obtained valid credentials for a standard user account can exploit this vulnerability by crafting specific HTTP GET requests directed at the /sys/oss/file/queryById endpoint. By manipulating the request parameters and supplying arbitrary or guessed record identifiers, the attacker can force the server to return sensitive data associated with files uploaded by other users within the same tenant or system environment. The lack of object-level authorization checks means that the application trusts the client-supplied identifier without verifying if the current user is authorized to view it, effectively treating all file records as publicly accessible to any logged-in entity regardless of their role or permissions.
The operational impact of this vulnerability extends beyond simple data leakage, potentially leading to significant privacy violations and intellectual property theft depending on the nature of the stored files. The attacker can obtain original file names, which may reveal sensitive business context or personal information about other users. More critically, the disclosure of direct storage URLs allows for further exploitation vectors. These URLs often provide temporary or permanent access links to the actual binary content of the files. If these presigned URLs are not configured with short expiration times and strict IP restrictions, an attacker can download proprietary documents, confidential images, or sensitive records directly from the object storage service. This undermines the confidentiality integrity triad and compromises the trust model of multi-tenant applications where data isolation is paramount.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it relies on legitimate authentication to gain unauthorized access, and potentially T1530, Data from Cloud Storage Object Databases, if the attacker proceeds to exfiltrate the actual file contents via the disclosed URLs. The attack pattern is consistent with Insecure Direct Object References (IDOR), a common web application vulnerability where an application exposes internal implementation objects such as database keys or file paths directly to users without proper access control validation. This enables attackers to manipulate these references to gain unauthorized access to other users' data, bypassing the intended role-based access controls that should restrict visibility based on user identity and privileges.
To mitigate this risk, immediate remediation is required by implementing robust authorization checks within the OssFileController queryById handler. Developers must ensure that every request for file metadata verifies that the authenticated principal owns the resource or possesses explicit administrative rights to view it. This involves querying the database not just for the existence of the record but also validating the user_id associated with the file against the session's current user identity before returning any data. Additionally, security hardening measures should include implementing rate limiting on API endpoints to prevent automated enumeration attacks and ensuring that direct storage URLs are generated with short lifespans and restricted scopes. Regular code audits focusing on access control logic across all RESTful endpoints are recommended to identify similar gaps in other controllers within the JeecgBoot framework.