CVE-2026-50530: DataEase Information Disclosure Flaw

CVE-2026-50530 Overview

DataEase is an open source data visualization and analysis tool used by organizations to build dashboards and share analytical charts. CVE-2026-50530 is an Insecure Direct Object Reference (IDOR) vulnerability [CWE-639] affecting DataEase versions prior to 2.10.24. The share mode chart data interface validates only that the sceneId parameter matches the resourceId embedded in the link token. It does not validate whether the tableId or field identifiers in the request body actually belong to the shared resource. An attacker holding a valid share link token can substitute dataset identifiers in a POST /de2api/chartData/getData request and retrieve unauthorized data from other datasets.

Critical Impact
Any user with a valid DataEase share link can enumerate and exfiltrate data from datasets they were never granted access to, breaking the tenant isolation model of shared dashboards.

Affected Products

DataEase open source data visualization and analysis tool
All DataEase versions prior to 2.10.24
Deployments exposing the /de2api/chartData/getData share mode endpoint

Discovery Timeline

2026-07-07 - CVE-2026-50530 published to NVD
2026-07-08 - Last updated in NVD database
v2.10.24 - DataEase releases patched version resolving the share link authorization flaw

Technical Details for CVE-2026-50530

Vulnerability Analysis

DataEase implements share links by issuing a JSON Web Token (JWT) that binds a viewer to a specific shared resource. When the frontend requests chart data, it sends the sceneId (the chart being viewed) along with a tableId and field IDs describing which dataset columns to query. The backend ChartDataManage component compares sceneId against the resourceId claim in the token but never re-validates that the tableId and field IDs belong to that resource. An attacker replays a legitimate share request, swaps the tableId for another dataset ID discovered through enumeration, and receives the resulting query response. The flaw is classified as CWE-639, Authorization Bypass Through User-Controlled Key.

Root Cause

The root cause is missing server-side authorization checks on secondary object identifiers. The share token grants scoped read access to a single scene, but the query pipeline trusts client-supplied dataset references without cross-checking them against the token's authorized resource graph. The patch introduces a new chartViewManege.checkLinkChart(view) call and decodes the JWT server-side to enforce that the requested view and dataset belong to the shared scene.

Attack Vector

Exploitation requires network access to the DataEase instance and possession of any valid share link. The attacker submits a POST /de2api/chartData/getData request containing the legitimate sceneId and share token, but with tableId and field IDs pointing to a different dataset. The server returns unauthorized data. No user interaction is required beyond obtaining or being given a share link.

java

// Patch: core/core-backend/src/main/java/io/dataease/chart/manage/ChartDataManage.java
            view.setChartExtRequest(chartExtRequest);
        }

+       chartViewManege.checkLinkChart(view);
+
        //excel导出，如果是从仪表板获取图表数据，则仪表板的查询模式，查询结果的数量，覆盖图表对应的属性
        if (view.getIsExcelExport()) {
            view.setResultMode(ChartConstants.VIEW_RESULT_MODE.CUSTOM);

Source: GitHub Commit c4e85a9

java

// Patch: core/core-backend/src/main/java/io/dataease/chart/manage/ChartViewManege.java
 package io.dataease.chart.manage;

+import com.auth0.jwt.JWT;
+import com.auth0.jwt.interfaces.DecodedJWT;
 import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper;

The patch adds JWT decoding to ChartViewManege so the backend can inspect the share token's claims and confirm that the requested chart and dataset are within the token's authorized scope.

Detection Methods for CVE-2026-50530

Indicators of Compromise

Requests to POST /de2api/chartData/getData where the tableId in the body does not match any dataset associated with the accompanying share link.
Repeated getData requests from the same share token targeting sequential or varied tableId values, indicating dataset enumeration.
Unusually large volumes of chart data returned to unauthenticated share link sessions.

Detection Strategies

Enable DataEase access logging and correlate sceneId, resourceId, and tableId fields to flag mismatches in share mode traffic.
Deploy a reverse proxy or WAF rule that inspects /de2api/chartData/getData POST bodies and rejects requests whose tableId is not on an allowlist for the presented token.
Baseline share link usage patterns and alert on tokens issuing queries against multiple distinct datasets in a short time window.

Monitoring Recommendations

Monitor DataEase application logs for HTTP 200 responses on chartData/getData originating from anonymous share link sessions.
Track outbound response sizes on share endpoints to detect bulk data extraction.
Audit issued share tokens periodically and revoke tokens that show anomalous dataset access patterns.

How to Mitigate CVE-2026-50530

Immediate Actions Required

Upgrade DataEase to version 2.10.24 or later, which contains the checkLinkChart authorization enforcement.
Rotate or revoke all previously issued share link tokens after upgrading to invalidate any tokens that may have been abused.
Inventory published share links and remove any that are no longer required to reduce exposure.

Patch Information

The fix is available in DataEase v2.10.24. The corrective commit c4e85a9 adds a call to chartViewManege.checkLinkChart(view) inside ChartDataManage and introduces JWT decoding in ChartViewManege to validate that the requested chart view and its underlying dataset belong to the scene authorized by the share token. Reference the GitHub Security Advisory GHSA-qcf4-345v-6vg9 and the GitHub Release v2.10.24 notes for full remediation details.

Workarounds

Restrict network access to the DataEase /de2api/chartData/getData endpoint to trusted networks until the upgrade is applied.
Disable the share link feature in DataEase administrative settings if it is not operationally required.
Front DataEase with a reverse proxy that validates the association between the share token, sceneId, and tableId on each request.

bash

# Example NGINX rule to block anonymous share-mode chartData calls until patched
location = /de2api/chartData/getData {
    if ($http_x_de_token = "") { return 403; }
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://dataease-backend;
}