CVE-2026-111633 in ZKEACMS
Summary
by MITRE • 10/16/2026
ZKEACMS through 4.4 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge REST API JWT bearer tokens using a hard-coded HMAC-SHA256 signing key in JwtBearerDefaults.cs. Attackers can sign a token with the Name claim set to 'admin' to call ApiAuthorize endpoints, modifying articles and products and reading form submissions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in ZKEACMS versions through 4.4 represents a critical authentication bypass flaw rooted in improper handling of cryptographic keys within its JSON Web Token implementation. The core technical defect lies in the JwtBearerDefaults.cs file, which utilizes a hard-coded HMAC-SHA256 signing key for validating and generating bearer tokens. In secure software architecture, secret keys used for digital signatures must be generated dynamically with high entropy and stored securely, such as in environment variables or dedicated secrets management systems, rather than being embedded directly into the source code. By using a static, known key that is distributed alongside the application binary, ZKEACMS effectively nullifies the security guarantees provided by JWT authentication mechanisms. This design choice allows any external actor to independently compute valid signatures for arbitrary tokens without possessing legitimate credentials or access to protected infrastructure secrets.
From an operational perspective, this flaw enables unauthenticated attackers to forge administrative-level bearer tokens with minimal effort. By constructing a JSON Web Token that includes the Name claim set to 'admin' and signing it using the exposed hard-coded key, an attacker can successfully authenticate against ApiAuthorize endpoints. This bypasses all intended access controls, granting the adversary full administrative privileges within the application context. The impact is severe as it allows for complete compromise of data integrity and confidentiality. Attackers are able to modify critical content such as articles and products, potentially defacing websites or injecting malicious information. Furthermore, they can read sensitive form submissions, which may contain personally identifiable information, business secrets, or other confidential user data depending on the specific deployment context of ZKEACMS.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials, as it involves the use of a static password, key, or passphrase that is hard-coded into an application and cannot be changed by users. Additionally, the exploitation technique maps to MITRE ATT&CK techniques related to Authentication Bypass using Alternate Channels or Invalid Authentication Credentials, specifically focusing on forging valid authentication tokens due to weak cryptographic implementation. The ability to manipulate database records via API endpoints also touches upon CWE-269: Improvement of Privileges and CWE-352: Cross-Site Request Forgery if the forged token is used in subsequent requests that rely solely on cookie or header validation without additional state checks, although the primary vector here is direct authentication bypass.
To mitigate this vulnerability, immediate remediation requires replacing the hard-coded signing key with a securely generated random secret of sufficient length and complexity. This new secret must be stored outside of the source code repository, preferably in environment variables or a secure vault service that restricts access to authorized deployment processes only. Developers should ensure that the application reads this configuration at runtime rather than compiling it into the binary. Furthermore, implementing key rotation policies is recommended to limit the window of exposure if a secret were ever compromised. For existing deployments running version 4.4 and below, upgrading to a patched version where this hard-coded default has been removed or made configurable via secure environment variables is essential. Until an upgrade can be performed, restricting network access to the API endpoints and monitoring for anomalous JWT signatures may provide limited defensive value, though these are not substitutes for fixing the underlying cryptographic flaw.