CVE-2026-46684: DataEase Auth Bypass Vulnerability

CVE-2026-46684 Overview

DataEase is an open source data visualization and analysis tool used to build dashboards and analytics workflows. Versions prior to 2.10.23 contain a JWT signature verification flaw [CWE-347] in enterprise token handling. The TokenFilter#doFilter() method passes X-DE-TOKEN header values to TokenUtils.validate(), which only checks token presence and length. The userBOByToken(token) routine then calls JWT.decode() without verifying the token signature. When licenseValid=true, attackers can forge tokens with attacker-chosen uid and oid values and impersonate any user, including administrators.

Critical Impact
Unauthenticated attackers can forge valid enterprise session tokens over the network and gain full administrative access to DataEase instances, exposing dashboards, data sources, and enabling downstream command execution.

Affected Products

DataEase enterprise builds prior to version 2.10.23
DataEase deployments where licenseValid=true
Fixed release: DataEase 2.10.23

Discovery Timeline

2026-07-15 - CVE-2026-46684 published to the National Vulnerability Database
2026-07-15 - Last updated in NVD database
v2.10.23 - DataEase releases patched version on GitHub

Technical Details for CVE-2026-46684

Vulnerability Analysis

The flaw resides in the enterprise authentication path handled by TokenFilter#doFilter(). When a request carries the X-DE-TOKEN header, the filter forwards the value to TokenUtils.validate(). That routine performs only two checks: the token must be non-blank and meet a minimum length. It does not verify the cryptographic signature.

Downstream, userBOByToken(token) calls JWT.decode(), a method that parses claims without validating the signing key. As long as the license state reports licenseValid=true, the decoded claims are trusted. Attackers supply arbitrary uid and oid claims to assume any identity, including administrative accounts, and reach protected API endpoints.

Root Cause

The root cause is Improper Verification of Cryptographic Signature [CWE-347]. The code path uses JWT.decode() instead of a verifying method such as JWT.require(algorithm).build().verify(). Presence and length checks provide no cryptographic assurance about token origin or integrity.

Attack Vector

An unauthenticated remote attacker crafts a JWT with a chosen uid and oid, an arbitrary signature, and sends it in the X-DE-TOKEN header to a DataEase endpoint. The filter accepts the token, and the application binds the request to the impersonated user context. This grants access to enterprise features and, per vendor advisory GHSA-gp6v-f7mm-458v, has been linked to unauthorized command execution behavior.

java

// Patch excerpt: sdk/common/src/main/java/io/dataease/auth/filter/CommunityTokenFilter.java
if (StringUtils.isNotBlank(token) && ObjectUtils.isNotEmpty(userBO = AuthUtils.getUser()) && ObjectUtils.isNotEmpty(userId = userBO.getUserId()) && !LicenseUtil.licenseValid()) {
    String secret = null;
    if (ObjectUtils.isEmpty(CommonBeanFactory.getBean("loginServer"))) {
-       String pwd = SubstituleLoginConfig.getPwd();
-       secret = Md5Utils.md5(pwd);
+       secret = SubstituleLoginConfig.getTokenSecret();
    } else {
        Object apisixCacheManage = CommonBeanFactory.getBean("apisixCacheManage");
        Method method = DeReflectUtil.findMethod(apisixCacheManage.getClass(), "userCacheBO");

Source: GitHub Commit 3efda9d. The patch replaces the MD5-of-password derived secret with a dedicated token secret retrieved from SubstituleLoginConfig.getTokenSecret(), and removes the Md5Utils import from SubstituleLoginServer.java.

Detection Methods for CVE-2026-46684

Indicators of Compromise

Requests to DataEase endpoints containing an X-DE-TOKEN header where the JWT signature does not match the server's signing secret.
Successful authenticated actions attributed to uid values that were never issued a token by the login server.
Access log entries showing privileged API calls without a preceding successful /login sequence.
Unexpected creation, modification, or execution of DataEase data source connections shortly after anonymous traffic.

Detection Strategies

Parse the X-DE-TOKEN header at the reverse proxy or WAF and validate the JWT signature independently before it reaches DataEase.
Correlate uid/oid values in application logs against the identities issued by the DataEase login server.
Alert on JWTs signed with none algorithm, weak keys, or algorithms not used by the deployment.

Monitoring Recommendations

Enable verbose logging on TokenFilter and record every token acceptance event with the source IP and derived user ID.
Monitor DataEase instances for outbound child processes spawned by the Java runtime, indicating post-authentication command execution.
Track spikes in requests to enterprise-only endpoints from IP addresses that never completed an interactive login.

How to Mitigate CVE-2026-46684

Immediate Actions Required

Upgrade DataEase to version 2.10.23 or later without delay.
Rotate any JWT signing secrets and invalidate active enterprise sessions after upgrade.
Restrict network exposure of DataEase management endpoints to trusted networks or VPN only.
Audit administrative actions performed since the vulnerable version was deployed for signs of forged-token activity.

Patch Information

The fix is available in DataEase v2.10.23. Details are documented in GitHub Security Advisory GHSA-gp6v-f7mm-458v and implemented in commit 3efda9d, which replaces the MD5-derived secret with a dedicated token secret and enforces proper JWT verification.

Workarounds

Place a reverse proxy in front of DataEase that strips or validates X-DE-TOKEN headers before forwarding requests.
Temporarily disable enterprise/license-gated features so the vulnerable licenseValid=true branch is not reached.
Enforce IP allowlisting on DataEase administrative routes until the upgrade is completed.

bash

# Verify DataEase version after upgrade
curl -s https://dataease.example.com/de2api/system/versionInfo | jq '.data.version'
# Expected output: "v2.10.23" or newer

# Nginx snippet to block requests carrying an X-DE-TOKEN header from untrusted networks
location / {
    if ($http_x_de_token != "") {
        set $token_check 1;
    }
    if ($remote_addr !~ ^10\.) {
        set $token_check "${token_check}1";
    }
    if ($token_check = "11") {
        return 403;
    }
    proxy_pass http://dataease_backend;
}