Description

DataEase versions before 2.10.26 omit object-level authorization checks on geographic information, dashboard linkage, and chart detail REST endpoints, allowing authenticated users to access resources belonging to other users. Attackers can overwrite or delete map geometry, modify dashboard linkages, and retrieve chart metadata and configuration for resources they do not own by supplying arbitrary identifiers in requests.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.3",
  "pubDate": "2026-08-31T11:16:41.467Z",
  "pubdate": "2026-08-31T11:16:41.467Z",
  "executiveSummary": "DataEase versions prior to 2.10.26 are susceptible to a Broken Object Level Authorization (BOLA) vulnerability. This security flaw originates from the application's failure to perform adequate authorization checks when processing requests for geographic information, dashboard linkage configurations, and chart detail REST endpoints.\nThe vulnerability allows authenticated users to bypass intended access controls and interact with resources owned by other users. An attacker can manipulate resource identifiers within API requests to perform unauthorized operations, including the modification or deletion of sensitive map geometry data, the alteration of dashboard linkages, and the exfiltration of private chart metadata and configurations.\nThe risk implication is significant as it facilitates unauthorized data access and integrity compromise across the platform. Exploitation requires the attacker to be an authenticated user within the DataEase environment; no elevated administrative privileges are necessary to conduct these unauthorized actions. Given the nature of the impacted endpoints, this flaw enables lateral movement into the datasets and configurations of other users, potentially leading to widespread information disclosure and disruption of analytical workflows.",
  "technicalDetails": "The vulnerability resides within the REST API architecture of DataEase, specifically affecting endpoints responsible for handling geographic data, dashboard associations, and chart metadata. The root cause is a deficiency in the backend authorization layer, which fails to validate whether the authenticated requester possesses the necessary permissions to access, modify, or delete the resource referenced by the provided identifier (ID) in the request parameters.\nDuring normal operation, the application should verify the relationship between the authenticated session user and the specific object requested. However, in the affected versions, the API implementation relies solely on the integrity of the input ID rather than enforcing an ownership verification check. Consequently, the application processes requests against any resource ID provided, regardless of the user's actual permission scope.\nThe attack flow follows a predictable pattern of Insecure Direct Object Reference (IDOR) manipulation. An attacker first performs reconnaissance to capture valid API requests destined for the vulnerable endpoints—specifically those involving map, dashboard, or chart resource IDs. By observing the API schema, the attacker identifies the parameters representing the resource identifier. To exploit the vulnerability, the attacker modifies these identifiers to point to resources belonging to other users or departments within the same DataEase instance. Because the application logic lacks a mandatory server-side check to confirm the user's authorization to access the targeted object, the backend processes the request as if it were legitimate.\nExploitation allows for several critical impact vectors. For geographic data, an attacker can supply an arbitrary ID to execute DELETE or PUT requests, effectively overwriting or erasing map geometries that they do not own. For dashboard linkages, the attacker can manipulate the configuration to disrupt user workflows or create unauthorized associations. Regarding chart endpoints, the attacker can supply IDs of charts they lack access to, forcing the application to return detailed metadata and configuration payloads that may contain sensitive analytical insights. The vulnerability is persistent across the geographic information, dashboard linkage, and chart detail components, and is effectively triggered by any authenticated user within the network exposure scope. There are no secondary requirements beyond obtaining the target object identifier, which may be discovered via enumeration or predictable URL patterns."
}