CVE-2026-23958: Verified Repro With Script Download

DataEase signs its authentication JWTs with an HMAC-SHA256 key derived from the admin password. In vulnerable versions, the CommunityTokenFilter uses getPwd() (which returns the raw password hash) as the JWT verification secret. Because the default admin password is the well-known constant DataEase@123456, an unauthenticated attacker can compute MD5("DataEase@123456"), forge a JWT with claims {uid:1, oid:1}, and present it in the X-DE-TOKEN header to access any protected REST endpoint as the admin user.

• Package/Component: io.dataease.auth.filter.CommunityTokenFilter (sdk/common) and io.dataease.xpack.permissions.login.bo.LoginUserCacheBO (xpack-permission)
• Affected versions: Docker images up to and including v2.10.10 are demonstrably vulnerable. Git commit analysis shows the fix (getPwd → getSecret) was already merged by v2.10.20, but the ticket incorrectly labels v2.10.20 as vulnerable.
• Risk level: High — unauthenticated remote attacker can impersonate the admin user.
• Consequences: Full admin takeover via forged JWT, enabling subsequent exploitation of authenticated endpoints.

Root Cause

In the CommunityTokenFilter.doFilter method, when the application is running with an active loginServer bean (the standard Docker image configuration), the filter reaches the else branch and derives the JWT secret from the user cache object:

Object apisixCacheManage = CommonBeanFactory.getBean("apisixCacheManage");
Method method = DeReflectUtil.findMethod(apisixCacheManage.getClass(), "userCacheBO");
Object o = ReflectionUtils.invokeMethod(method, apisixCacheManage, userId);
Method pwdMethod = DeReflectUtil.findMethod(o.getClass(), "getPwd");  // vulnerable
Object pwdObj = ReflectionUtils.invokeMethod(pwdMethod, o);
secret = pwdObj.toString();

In the vulnerable code (getPwd), secret is simply the user's password hash (504c8c8dfcbbe5b50d676ad65ef43909 for the default admin). This is trivially derivable by anyone who knows the default password. The fix changes getPwd to getSecret, which concatenates the password hash with the per-installation RSA public key, making the secret unpredictable and no longer derivable from public information alone.

Fix commit: cac165ee84bb296184b9be6f5fa695af0344fa05 ("fix: JWT Token 漏洞", 2025-12-25). This commit is already present in git tag v2.10.20 and in Docker images v2.10.20+.

Reproduction Steps

1. Run repro/reproduction_steps.sh
2. The script:
   • Starts a MySQL 8 container and a DataEase v2.10.10 container (vulnerable)
   • Waits for the API to respond on http://127.0.0.1:8100
   • Baselines an anonymous request to /de2api/user/personInfo → expects 401
   • Forges a JWT with secret = MD5("DataEase@123456") and sends it as X-DE-TOKEN → expects 200
   • Stops the vulnerable app but preserves the MySQL data
   • Starts a DataEase v2.10.21 container against the same MySQL data
   • Replays the identical forged JWT → expects 401 with DE-GATEWAY-FLAG header
3. Expected evidence:
   • logs/vulnerable_attack_response.txt shows HTTP 200
   • logs/fixed_attack_response.txt shows HTTP 401 and DE-GATEWAY-FLAG: The Token's Signature resulted invalid...

Evidence

• logs/repro_run1.log — first successful execution of reproduction_steps.sh
• logs/repro_run2.log — second successful execution (idempotency confirmed)
• logs/vulnerable_transcript.txt — summary of v2.10.10 test results
• logs/fixed_transcript.txt — summary of v2.10.21 test results
• logs/vulnerable_attack_response.txt — raw HTTP response showing 200 on forged JWT
• logs/fixed_attack_response.txt — raw HTTP response showing 401 + DE-GATEWAY-FLAG

Key excerpts from v2.10.10 (vulnerable):

HTTP/1.1 200
X-DE-EXECUTE-VERSION: 2.10.10
...
{"code":60003,"msg":"缺少许可证","data":null}

(The 200 status proves the JWT signature was accepted; the downstream "missing license" error is irrelevant to the auth bypass.)

Key excerpts from v2.10.21 (fixed):

HTTP/1.1 401
X-DE-EXECUTE-VERSION: 2.10.21
DE-GATEWAY-FLAG: The%20Token%27s%20Signature%20resulted%20invalid%20when%20verified%20using%20the%20Algorithm%3A%20HmacSHA256

Recommendations / Next Steps

1. Upgrade to DataEase v2.10.20 or later. The fix commit is already present in those builds.
2. Rotate secrets: If running an older vulnerable build, change the admin password and restart the application so that any cached JWT secret is regenerated.
3. Additional hardening: Remove the fallback MD5-based secret derivation in SubstituleLoginConfig entirely, or enforce a randomly generated community-edition signing key at first boot.
4. Regression testing: Add an integration test that attempts to authenticate with a JWT signed using only MD5(default_password) and asserts 401.

Additional Notes

• Idempotency: reproduction_steps.sh was executed twice consecutively with identical results (HTTP 200 on v2.10.10, HTTP 401 on v2.10.21).
• Version discrepancy: The ticket specifies v2.10.20 as vulnerable and v2.10.21 as fixed. However, binary analysis of the official Docker images shows that v2.10.20 already contains the getSecret() fix. The last vulnerable official Docker image we could identify is v2.10.10, which still uses getPwd(). The reproduction script therefore uses v2.10.10 as the vulnerable baseline and v2.10.21 as the fixed baseline to ensure the vulnerability is actually demonstrated at runtime.
• Environment: Docker 27.x, Ubuntu 22.04 sandbox, images pulled from registry.cn-qingdao.aliyuncs.com/dataease/.

The official fix for CVE-2026-23958 (commit cac165ee84bb296184b9be6f5fa695af0344fa05) only patched the xpack/enterprise JWT verification path in CommunityTokenFilter. The community-edition fallback path, which is triggered when the proprietary loginServer and apisixCacheManage beans are absent, was left completely untouched. In this fallback path CommunityTokenFilter still verifies JWTs with Md5Utils.md5(SubstituleLoginConfig.getPwd()), and SubstituleLoginServer still signs them with the same secret. Because SubstituleLoginConfig.getPwd() defaults to the well-known string DataEase@123456, an unauthenticated attacker can compute the HMAC secret, forge an admin JWT, and access any authenticated REST endpoint on a pure open-source (no-xpack) build of v2.10.21. This constitutes a bypass of the patch.

Fix Coverage / Assumptions

• What the fix changes: One line in CommunityTokenFilter.doFilter inside the else branch (loginServer present): getPwd() → getSecret().
• What the fix assumes: All production deployments include the proprietary xpack JARs (xpack-base.jar, xpack-permission.jar, xpack-sync.jar), so the loginServer bean is always present and the else branch is always taken.
• What the fix does NOT cover:
  • The if branch in CommunityTokenFilter (loginServer absent).
  • SubstituleLoginServer.localLogin, which still signs JWTs with Md5Utils.md5(pwd).
  • SubstituleLoginConfig.getPwd(), which still defaults to DataEase@123456.

Variant / Alternate Trigger

• Variant type: Bypass of the official patch via an alternate deployment mode.

• Entry point: Any authenticated REST endpoint reachable when DataEase is deployed from the public GitHub repository (or any build where xpack JARs are stripped).

• Trigger mechanism:

  1. Attacker computes secret = MD5("DataEase@123456").
  2. Attacker forges a JWT with claims {uid: 1, oid: 1} signed with HS256(secret).
  3. Attacker sends the forged JWT in the X-DE-TOKEN header to an endpoint such as /de2api/menu/query.
  4. TokenFilter decodes the JWT (without signature verification) and extracts uid/oid.
  5. CommunityTokenFilter.doFilter reaches the if branch because CommonBeanFactory.getBean("loginServer") is empty.
  6. The filter derives secret = Md5Utils.md5(SubstituleLoginConfig.getPwd()), which equals the attacker's secret, so the JWT passes verification.
  7. The request proceeds as the admin user.

• Package/Component: io.dataease.auth.filter.CommunityTokenFilter (sdk/common) and io.dataease.substitute.permissions.login.SubstituleLoginServer (core/core-backend)

• Affected versions: v2.10.21 when built/deployed without proprietary xpack JARs (pure open-source/community edition).

• Risk level: High — identical to the original CVE: unauthenticated remote attacker can impersonate the admin user.

• Consequences: Full admin takeover, enabling exploitation of downstream authenticated endpoints.

Root Cause

The fix changed only the xpack path:

// CommunityTokenFilter.java (v2.10.21)
if (ObjectUtils.isEmpty(CommonBeanFactory.getBean("loginServer"))) {
    // UNCHANGED — still uses default password hash as secret
    String pwd = SubstituleLoginConfig.getPwd();
    secret = Md5Utils.md5(pwd);
} else {
    // FIXED — now uses getSecret() instead of getPwd()
    Object apisixCacheManage = CommonBeanFactory.getBean("apisixCacheManage");
    ...
    Method pwdMethod = DeReflectUtil.findMethod(o.getClass(), "getSecret");
    ...
}

And the community login controller remains unchanged:

// SubstituleLoginServer.java (v2.10.21)
String md5Pwd = Md5Utils.md5(pwd);
return generate(tokenUserBO, md5Pwd);

When xpack is absent, both signing and verification use the trivially derivable MD5(default_password) secret.

Reproduction Steps

1. Run vuln_variant/reproduction_steps.sh.
2. The script builds a dataease:v2.10.21-no-xpack image by removing the proprietary xpack JARs from the official v2.10.21 Docker image.
3. It starts a MySQL container and the no-xpack DataEase container.
4. It sends a forged JWT (signed with MD5("DataEase@123456")) to /de2api/menu/query.
5. Expected result: HTTP 200 with actual menu data (bypass confirmed).
6. It then starts the regular v2.10.21 DataEase (with xpack JARs) and repeats the request.
7. Expected result: HTTP 401 with DE-GATEWAY-FLAG: The Token's Signature resulted invalid... (fix works).

Evidence

• logs/variant_test.log — Full execution transcript showing both test runs.
• logs/no_xpack_bypass_headers.txt — HTTP 200 response headers from no-xpack v2.10.21.
• logs/no_xpack_bypass_body.txt — JSON menu data returned (proof of authenticated access).
• logs/no_xpack_baseline_headers.txt — HTTP 401 baseline without token.
• logs/full_bypass_headers.txt — HTTP 401 response from regular v2.10.21 with same forged JWT.
• logs/docker_build_no_xpack.log — Docker build log for the no-xpack image.

Key excerpts:

No-xpack v2.10.21 forged-JWT response status: 200
No-xpack v2.10.21 baseline response status: 401
Regular v2.10.21 forged-JWT response status: 401

Recommendations / Next Steps

1. Extend the fix to the community fallback path: In CommunityTokenFilter.doFilter, replace Md5Utils.md5(SubstituleLoginConfig.getPwd()) with a per-instance random secret (e.g., generated on first startup and persisted in substitule.json).
2. Synchronize SubstituleLoginServer signing secret: Ensure SubstituleLoginServer.generate() uses the same per-instance random secret, not Md5Utils.md5(pwd).
3. Deprecate password-derived JWT secrets entirely: Whether in xpack or community mode, the JWT signing key must never be derivable from any user-facing value, including the admin password.
4. Add a startup secret generation step: If substitule.json does not exist, generate a cryptographically random secret instead of defaulting to a hardcoded password.

Additional Notes

• Idempotency: The reproduction script was executed twice (run1 and run2) and produced identical results (200 bypass on no-xpack, 401 rejection on regular) in both runs.
• Trust boundary: The attacker only needs network access to the DataEase server; no local file access or prior authentication is required.
• Limitation: The bypass only manifests when the proprietary xpack JARs are absent from the classpath. However, this is the default state for anyone building from the public GitHub repository, making it a significant exposure.