CVE-2026-23958 is a critical flaw (CVSS 9.8) in DataEase, an open source data visualization tool. Before version 2.10.19 it used the MD5 hash of the user's password as the JWT signing secret, which lets an attacker guess the admin password offline. There is no workaround. Upgrade to 2.10.19, then change passwords.
What's affected
DataEase versions before 2.10.19. The GitHub advisory lists 2.10.19 as the patched version and says no workarounds are known. The advisory recommends upgrading.
How to check if you're exposed
Check the version in the DataEase interface, or the image tag if you deploy with Docker:
docker ps --format "table {{.Names}}\t{{.Image}}"
Anything below 2.10.19 is affected. Exposure grows when the DataEase instance is reachable from the internet, because the attack uses API endpoints that verify tokens, and those can be hit repeatedly.
What to do now
- Upgrade DataEase to 2.10.19 or later.
- After the upgrade, change the admin password and the passwords of other privileged users, since the old ones may have been guessed. Use long, random passwords.
- Restrict access to DataEase to your internal network or behind a VPN or SSO proxy.
- Review API access logs for a high volume of token verification requests from a single source.
- Review what data sources DataEase can reach, because a stolen admin session also exposes those connections.
Why it matters
The weakness is CWE-522, insufficiently protected credentials. A signing secret should be a random value that the server holds. Here it was derived from the user's password, so anyone holding a signed token can test password guesses locally against it. Passwords are the weak part, and the guess rate depends on the attacker's hardware instead of on a server that can throttle.
The advisory describes the brute force path through API endpoints that verify JWTs and are not monitored. The research write-up from OX Security is linked from the record. The record does not list this CVE as known exploited.
A single design choice, deriving a key from something a human picks, turns a token into a password oracle. Keys for signing should come from a secrets store or a random generator, never from user input.
Reading the severity score
The record gives a CVSS base score of 9.8, published 2026-01-22. In the vector, the attacker works over the network, needs no account, and the attack is low in complexity. User interaction is not needed. Impact on confidentiality is high, on integrity high and on availability high.
A base score describes the flaw in general, not your risk. Weigh it against how exposed your instance is and what it can reach. The Gold page for the CVE keeps the score, weakness and references together.
Hardening beyond the patch
This flaw is a lesson about secret handling, and the response should reach past one product.
Start with rotation. After upgrading, change the administrator password and any other password that a DataEase user might have reused elsewhere. The advisory describes password guessing against signed tokens, so a weak or reused password is the thing at risk. Use a password manager and long random values.
Next, look at the tokens. Sessions that were issued before the upgrade were signed with the old scheme. Ask the vendor docs or check the release notes about how to invalidate existing sessions, and do it, so old tokens cannot be replayed.
Then look at the access path. A data visualization tool usually connects to databases and warehouses, which means its stored connection credentials are as valuable as the admin login. Review which data sources it can reach, give each one a read only account where that is enough, and rotate the credentials if the instance was exposed to the internet.
Add monitoring for the specific behavior the advisory mentions. Brute force through endpoints that verify tokens shows up as many requests from one address with invalid tokens. Alert on high rates of authentication failures at your reverse proxy, and add rate limiting there, because the application itself did not watch these endpoints.
Finally, make the lesson portable. Search your own code for signing keys that are derived from user data, such as hashes of passwords or emails. A signing key should be random, long and stored in a secrets manager, and it should be rotated by an administrator, not by a user changing their password.
If you run several internal tools, add a short check to your onboarding of new software: where do session and signing secrets come from, and can they be rotated?
Find it across your own code
To see which of your packages are affected, the free in-browser dependency scan at gold.safeguard.sh/scan takes a manifest and lists known vulnerabilities. Reachability analysis then helps you judge whether your code calls the vulnerable path, so you can order the work.
Quick check
Will a strong admin password protect me on the old version?
It makes guessing much harder, but the advisory lists no workaround other than upgrading. Do the upgrade.
Do I need to rotate passwords after patching?
It is a sensible precaution. The old password may have been guessed from captured tokens before you patched.
Sources
Last reviewed: 19 October 2026.
