DataEase CVE-2026-50530

Exploitation requires possession of a valid DataEase share-link token (PR:L) - i.e., the target instance must have the share feature enabled and a link issued to the attacker or otherwise obtained by them; a fully unauthenticated outsider with no token cannot exploit it. Given such a token, the attacker sends a crafted POST /de2api/chartData/getData over the network (AV:N/AC:L) in which the sceneId still matches the token's resourceId but the tableId and field IDs are replaced with those of an unrelated dataset. Limiting factors: sharing must be turned on and a link distributed, and impact is confined to reading data the DataEase backend can query (confidentiality only, no write or DoS); instances that do not use share links, or that have already upgraded to 2.10.24, are not exploitable.

The vendor CVSS 4.0 score is 7.1 (High) with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N - network reachable, low complexity, no attack requirements, but requiring low privileges (PR:L) in the form of a valid share-link token, and impacting confidentiality only (VC:H, no integrity or availability effect). This is internally consistent: it is a read-only data-exposure flaw, not RCE. Real-world risk is moderate-to-high where DataEase share links are distributed to semi-trusted or external users, since any such recipient can pivot to unauthorized datasets with a single crafted POST. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit is identified at time of analysis, so there is no evidence of active exploitation or automated weaponization. The PR:L requirement (must possess a share token) is the main limiting factor separating this from a fully unauthenticated data breach; treat it as a priority for internet-exposed instances that hand out share links broadly, and lower priority for instances where sharing is disabled or tightly scoped internally.

An organization shares a single DataEase chart with an external partner via a share link. The partner (or anyone who obtains that link token) sends POST /de2api/chartData/getData with the valid sceneId but substitutes the tableId and field IDs of a sensitive internal dataset such as HR or financial data. Because the server only checks the scene against the token and not the dataset ownership, it returns the unauthorized rows, giving the attacker confidential data they were never meant to see. No public proof-of-concept is identified at time of analysis, but exploitation is straightforward request tampering.