CVE-2026-111633 is a High severity (CVSS 8.6) authentication bypass in ZKEACMS through 4.4. The REST API signs tokens with a key that is written into the source code, so anyone can create a valid admin token. We could not confirm a fixed version.
What's affected
The record says ZKEACMS through 4.4 is affected. The researcher write-up says it reviewed v4.4 and earlier releases that contain the same constants. An issue numbered 531 in the project repository is linked as the report. We found no fixed release, so check the SeriaWei/ZKEACMS repository.
The weakness is CWE-321, use of a hard-coded cryptographic key. Per the write-up, the HMAC-SHA256 key used for the API bearer tokens is a constant in the source file JwtBearerDefaults.cs, as are the issuer and audience. Token validation uses the same constants, with no per-install secret and no configuration override. We do not reproduce the key here.
The record says an attacker can sign a token with the Name claim set to admin and call the API endpoints that require authorization, modify articles and products, and read form submissions. Severity differs by source. The record gives 8.6 (High), and VulnCheck lists 8.8. The write-up calls it Critical.
How to check if you're exposed
Check your ZKEACMS version, in the project file or the release you deployed.
grep -rn "Version" --include=*.csproj . | head
Version 4.4 and earlier are in range per the record. Then check whether the REST API is reachable from untrusted networks. Look at your web server logs for API requests that carry bearer tokens, from clients that you do not recognise, and for changes to articles and products that your editors did not make.
Because the key is in public source code, every installation that has not changed it shares the same weakness, so reachability is what matters. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Block the REST API paths at your reverse proxy unless you use them, or limit them to known addresses.
- Check the project for a fixed release, and upgrade after you confirm it. A real fix needs a per-install secret that is not in the source.
- If you maintain a fork, move the signing key to configuration or a secret store, rotate it, and invalidate old tokens.
- Review content and form submissions for changes you did not make.
- Treat form submissions as exposed if the API was reachable, and follow your data breach process if they hold personal data.
Why it matters
A signing key is only a secret if it is secret. When the same key ships in the source of every install, anyone can read it and mint a valid token for any user name. The signature check passes, because the attacker used the right key.
The fix is not just a new constant. Each deployment needs its own random key, kept out of source control and rotated on a schedule. Scanners for hard-coded secrets find this kind of flaw quickly, and attackers use the same scanners. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
Why is a hard-coded key so serious?
Anyone who can read the source can sign tokens that the server accepts, with any user name, including admin.
Is there a fixed version?
We could not confirm one. Check the SeriaWei/ZKEACMS repository.
Sources
Last reviewed: 18 October 2026.
