CVE-2026-23958: DataEase: authentication bypass via password-derived HMAC JWT signing key

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/.