CVE-2026-57172: DataEase Auth Bypass Vulnerability

CVE-2026-57172 Overview

DataEase is an open source data visualization and analysis platform. Versions prior to 2.10.24 ship a hardcoded default signature key inside the ShareSecretManage component that governs passwordless share links. An attacker who obtains a valid passwordless share for any resource and user can forge linkToken JSON Web Tokens (JWTs) using the known key link-pwd-fit2cloud. The forged tokens bypass TokenFilter verification and grant backend access as the original share creator, even after the share has been revoked. The issue is tracked as [CWE-321: Use of Hard-coded Cryptographic Key] and fixed in version 2.10.24.

Critical Impact
Attackers can forge JWTs to impersonate share creators and access backend resources without authentication, defeating share revocation controls.

Affected Products

DataEase versions prior to 2.10.24
DataEase open source data visualization and analysis tool
DataEase X-Pack share and scheduled report components

Discovery Timeline

2026-07-07 - CVE-2026-57172 published to the National Vulnerability Database (NVD)
2026-07-08 - Last updated in NVD database

Technical Details for CVE-2026-57172

Vulnerability Analysis

The flaw resides in core/core-backend/src/main/java/io/dataease/share/manage/ShareSecretManage.java. The class historically used a static, publicly visible key to sign the linkToken JWTs issued for passwordless resource shares. Because the key value link-pwd-fit2cloud is embedded in the source repository, any actor with access to the DataEase codebase can reproduce the signing process offline.

Once a valid share is observed, an attacker can extract the share identifier and re-sign an arbitrary JWT payload using the hardcoded key. The resulting token satisfies signature verification inside TokenFilter, which is the sole gate protecting the backend share endpoints.

Root Cause

The root cause is a hardcoded cryptographic key ([CWE-321]) used to sign integrity-sensitive tokens. Revocation logic in DataEase relies on share state lookups only after signature validation succeeds. Because signature validation trusts a static, shared secret rather than a per-share or randomly generated server-side key, revoked shares remain forgeable indefinitely.

Attack Vector

Exploitation requires network access to a DataEase instance and one observation of any valid passwordless share. The attacker crafts a linkToken JWT with the desired resource ID and user context, signs it with link-pwd-fit2cloud, and submits it to the share endpoint. TokenFilter accepts the token and the backend serves the resource as the share creator, bypassing revocation state.

java

// Patch excerpt: core/core-backend/src/main/java/io/dataease/share/manage/ShareSecretManage.java
 package io.dataease.share.manage;
 
 import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper;
+import com.fasterxml.jackson.databind.ObjectMapper;
 import io.dataease.exception.DEException;
 import io.dataease.share.dao.auto.entity.XpackShare;
 import io.dataease.share.dao.auto.mapper.XpackShareMapper;
+import io.dataease.utils.LogUtil;
+import jakarta.annotation.PostConstruct;
 import jakarta.annotation.Resource;
 import lombok.Getter;
 import org.apache.commons.lang3.ObjectUtils;
 import org.apache.commons.lang3.StringUtils;
 import org.springframework.beans.factory.annotation.Value;
 import org.springframework.stereotype.Component;
 
+import java.io.File;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.security.SecureRandom;
+import java.util.Base64;
+import java.util.HashMap;
+import java.util.Map;
+
 @Component("shareSecretManage")
 public class ShareSecretManage {
 
+    private static final String SECRET_KEY = "linkPwd";

Source: GitHub Commit 356e83b. The patch replaces the static key with a persisted, randomly generated secret produced via SecureRandom and stored on first boot.

Detection Methods for CVE-2026-57172

Indicators of Compromise

Successful requests to DataEase share endpoints carrying linkToken JWTs signed with the string link-pwd-fit2cloud.
Access to shared resources that have been marked revoked or expired in the XpackShare table.
HTTP requests referencing share identifiers from user accounts that never legitimately viewed those shares.

Detection Strategies

Decode observed linkToken JWTs and compare the signing key or kid claim against the expected post-patch server-generated secret.
Correlate share access log entries with the revocation state of the corresponding share record and alert on mismatches.
Flag anomalous access patterns where a single client IP resolves multiple share tokens across unrelated resources or users.

Monitoring Recommendations

Enable verbose logging in TokenFilter to capture token subject, share ID, and validation outcome.
Ship DataEase application logs to a centralized SIEM and retain them long enough to review post-patch for prior forgery attempts.
Alert on any startup event where DataEase regenerates or fails to load the persisted share secret file after upgrade.

How to Mitigate CVE-2026-57172

Immediate Actions Required

Upgrade DataEase to version 2.10.24 or later on all instances.
Rotate or delete existing passwordless shares after upgrade so previously issued tokens cannot be replayed against the new key.
Restrict network access to DataEase share endpoints to trusted networks until patching is complete.

Patch Information

The fix is contained in GitHub commit 356e83b and released in DataEase 2.10.24. Details are published in GitHub Security Advisory GHSA-7cpg-f4cj-7pgm. The patch removes the hardcoded key and introduces a per-installation secret generated with SecureRandom and Base64-encoded on disk.

Workarounds

Disable the passwordless share feature until version 2.10.24 can be deployed.
Enforce reverse proxy authentication in front of DataEase to require an additional credential for /share routes.
Audit and revoke all outstanding passwordless share links, then reissue them only after upgrading.

bash

# Verify the DataEase version and confirm the patched build is running
docker exec dataease cat /opt/dataease/conf/version
# Expected output: 2.10.24 or later

# After upgrade, remove any legacy share secret material so a fresh key is generated
rm -f /opt/dataease/conf/share_secret.key
systemctl restart dataease