CVE-2026-75479 in JimuReport
Summary
by MITRE • 08/18/2026
JimuReport contains an authentication bypass vulnerability in the report folder template listing endpoint that allows unauthenticated attackers to enumerate all reports and retrieve share tokens. Attackers can use disclosed share tokens to access protected report endpoints and retrieve full report definitions including embedded SQL statements and live query data.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The JimuReport application, a popular open-source reporting tool often deployed within enterprise environments for business intelligence and data visualization, contains a critical authentication bypass vulnerability located in the endpoint responsible for listing report folder templates. This flaw fundamentally undermines the access control mechanisms designed to protect sensitive reporting assets. The vulnerability arises because the specific API endpoint used to retrieve metadata about report folders does not properly enforce session validation or token verification before returning results. Consequently, any actor with network connectivity to the JimuReport instance can interact with this endpoint without providing valid credentials, effectively treating a protected resource as public information.
From a technical perspective, the core issue is an improper access control failure where the server fails to verify the identity of the requesting user prior to processing the request for folder template listings. This oversight allows unauthenticated attackers to enumerate all available reports within the system. Beyond simple enumeration, the endpoint also discloses share tokens associated with these reports. These tokens are typically used as lightweight authentication mechanisms to allow users to view specific reports via a direct link without logging in. However, when exposed through this listing endpoint, they become powerful keys that can be reused by attackers to bypass standard login procedures entirely.
The operational impact of this vulnerability is severe due to the nature of reporting software which often aggregates data from multiple backend databases and systems. By exploiting this flaw, an attacker gains the ability to access protected report endpoints using the stolen share tokens. This leads to a comprehensive disclosure of full report definitions, which frequently include embedded SQL statements used to generate the visualizations. The exposure of these SQL queries reveals the underlying database schema, table structures, and query logic that may contain sensitive business intelligence data. Furthermore, because many reports are configured with live connections to databases, attackers can potentially retrieve real-time query results containing personally identifiable information, financial records, or other proprietary organizational data.
This vulnerability aligns closely with CWE-287 Improper Authentication and CWE-640 Weak Password Policy if the share tokens themselves are predictable or weakly generated. In terms of attack vectors, it corresponds to ATT&CK technique T1539 Steal Web Session Cookie as well as T1005 Data from Local System since the attacker is extracting data directly from the application's storage and connected databases without needing initial valid user credentials. The ability to enumerate resources also facilitates further reconnaissance, allowing attackers to map out the entire reporting infrastructure for more targeted attacks such as SQL injection or privilege escalation if other vulnerabilities exist in the exposed endpoints.
Mitigation strategies must address both immediate remediation and long-term security posture improvements. Organizations running JimuReport should immediately apply any available patches provided by the vendor that enforce strict authentication checks on all API endpoints, particularly those related to resource listing and metadata retrieval. If patching is not immediately possible, network-level controls such as firewall rules or Web Application Firewall (WAF) configurations can be implemented to restrict access to these specific endpoints from untrusted IP addresses. Additionally, administrators should review the implementation of share tokens; ensuring they are cryptographically secure, have short expiration times, and are tied strictly to single-use contexts rather than persistent access keys will reduce the window of opportunity for exploitation. Regular security audits focusing on API authentication flows and input validation are essential to prevent similar bypasses in other parts of the application.