DataEase EUVD-2026-42093

Exploitation requires the attacker to first obtain at least one passwordless share for a resource/user (the AT:P attack requirement in the CVSS 4.0 vector) so they can identify the target share creator and token structure; from there they use the known hardcoded key link-pwd-fit2cloud to forge linkTokens. No authentication is needed (PR:N) and no user interaction is required (UI:N), and the flaw affects default configurations of DataEase prior to 2.10.24. Limiting factors: the target must have issued a passwordless share, the DataEase share endpoint must be network-reachable to the attacker, and instances that only ever used password-protected shares present a smaller foothold; notably, revoking the original share does NOT stop exploitation, which is what makes the issue severe.

The CVSS 4.0 base score is 8.3 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N: network reachable, low complexity, no privileges and no user interaction, but a present Attack Requirement (AT:P) reflecting that the attacker must first obtain a passwordless share. Vulnerable-system confidentiality is High (read access to backend resources as the creator) with low integrity and no availability impact, and no scope/subsequent-system impact. No EPSS score, KEV listing, or POC was provided, so real-world exploitation is currently unproven; the AT:P requirement and the need to first acquire a passwordless share make this more of a targeted/opportunistic access-escalation issue than a mass-exploitable RCE. That said, the exploitation primitive is unusually reliable because the signing key is static and now public, so any environment that has ever issued a passwordless share should treat this as a real priority rather than a theoretical high-CVSS finding.

An attacker legitimately receives or discovers a passwordless share link to one DataEase resource and extracts a sample linkToken. Knowing the hardcoded key link-pwd-fit2cloud, they forge new linkToken JWTs for the share creator that pass TokenFilter validation, reading backend resources belonging to that user even after the administrator revoked the original share. No public POC was provided, but forgery is straightforward given a standard JWT library and the disclosed key.