Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify exposed ZKEACMS REST API
-
ExploitForge JWT using hard-coded signing key
-
ExecutionSet Name claim to 'admin'
-
ImpactModify articles/products and read form submissions
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Key management, no hard-coded keys
|
| Exploitation Conditions | Exploitation requires the target ZKEACMS instance (version <=4.4) to expose its REST API / ApiAuthorize endpoints, which authenticate via JWT bearer tokens signed with the key hard-coded in JwtBearerDefaults.cs. Because that key ships in the source and is the same across all installations, no non-default configuration, credentials, or user interaction is needed - any instance running the vulnerable API accepts attacker-forged tokens bearing the Name claim 'admin'. The primary limiting factor is reachability and use of the REST API: deployments that do not expose the API endpoints to the attacker reduce exposure, but the signing key itself is a default-condition weakness, not an opt-in one. |
| Impact | This is a genuine high-priority issue rather than an inflated CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a network-reachable, low-complexity, unauthenticated attack, which is fully consistent with CWE-321 (hard-coded cryptographic key): the HMAC-SHA256 signing secret is embedded in the shipped source (JwtBearerDefaults.cs), so any attacker can forge a valid admin JWT without credentials, with no conflict between the vector and the description. The 8.8 severity is driven by high integrity impact (VI:H - forging an admin token to modify articles and products) with lower confidentiality (VC:L - reading form submissions) and limited availability (VA:L). No EPSS score, KEV listing, or POC flag was supplied in the input, so there is no confirmed signal of active exploitation or published exploit code; however, the referenced HackMD write-up and VulnCheck advisory document the exact forging technique, meaning the barrier to weaponization is trivial. The real-world risk is therefore gated almost entirely by deployment footprint rather than technical difficulty: ZKEACMS is a niche open-source .NET CMS, so widespread opportunistic exploitation is less likely than targeted attacks against known installations. Net: technically easy and reliable to exploit, but modest real-world blast radius due to limited product prevalence. |
| Exploit ScenarioDerived | An unauthenticated attacker locates an internet-facing ZKEACMS instance (<=4.4) exposing its REST API, then uses the publicly known hard-coded HMAC-SHA256 key to mint a JWT bearer token with the Name claim set to 'admin'. With that forged token they call ApiAuthorize endpoints to modify articles and products and read submitted form data. Given AV:N/AC:L/PR:N/UI:N, no special timing, user interaction, or credentials are needed, and a detailed public write-up describes the method. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 16, 2026
Authentication bypass in ZKEACMS through 4.4 allows unauthenticated remote attackers to forge their own admin-level REST API JSON Web Tokens, because the HMAC-SHA256 key used to validate bearer tokens is hard-coded in JwtBearerDefaults.cs and is therefore identical on every installation. An attacker who signs a token with the Name claim set to 'admin' can call ApiAuthorize endpoints to modify articles and products and to read submitted form data, producing high integrity impact with limited confidentiality exposure (vendor CVSS 4.0 score 8.8; independently assessed as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L, i.e. unauthenticated and network-reachable). Neither CISA KEV nor a packaged exploit was reported in the provided intelligence, but the signing key is published in the project's public source repository and a public write-up describes the technique, so forgery is trivial for anyone who can reach the API; the main practical limiter is whether the REST API is exposed.
RemediationAI
No vendor-released patch was identified at time of analysis, so remediation must start with removing the shared secret and limiting reachability. First, replace the hard-coded key in src/ZKEACMS/Api/JwtBearerDefaults.cs (or, better, move signing to a per-deployment configuration value or an asymmetric RSA/ECDSA key so no shared secret ships in source), then rebuild and redeploy; this requires source modification and a rebuild because the value is compiled in, invalidates all previously issued tokens so users and API clients must re-authenticate, and must be coordinated with any other component that validates the same tokens. Second, restrict network access to the REST API and ApiAuthorize endpoints at the reverse proxy, firewall, or WAF so only trusted clients can reach them, and disable the API entirely on deployments that do not need it; both steps break legitimate headless or integration clients, so inventory API consumers before applying them. Third, add detection: log and alert on JWT authentication events where the Name claim is 'admin' but the request originates from an unexpected source or lacks a corresponding login, since forged tokens otherwise look like normal authenticated admin traffic. Monitor the upstream GitHub issue (https://github.com/SeriaWei/ZKEACMS/issues/531) and the VulnCheck advisory (https://www.vulncheck.com/advisories/zkeacms-through-4.4-authentication-bypass-via-hard-coded-jwt-signing-key) for the availability of a fixed release, and treat any instance that ran the vulnerable code as potentially compromised for content-integrity purposes.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
ZKEACMS is an ASP.NET Core content management system by SeriaWei (vendor name in the CPE, cpe:2.3:a:seriawei:zkeacms:*:*:*:*:*:*:*:*, whose wildcard version field matches any release). Its REST API authenticates with JWT bearer tokens handled by Microsoft's ASP.NET Core JWT bearer middleware, and the symmetric signing key used for HMAC-SHA256 validation is a constant compiled into the project at src/ZKEACMS/Api/JwtBearerDefaults.cs (lines 14-19) rather than a per-deployment secret. Because HMAC is symmetric, anyone who can read the key can both create and validate tokens, so no private key or leaked credential is needed; the same key also applies to every ZKEACMS installation running the affected code. The root cause is CWE-321 (Use of Hard-coded Cryptographic Key), and the impact is amplified by how the token's claims are consumed: BuilderAuthentication.cs (lines 41-52) maps the Name claim directly onto the authenticated principal, so a self-issued token bearing Name="admin" is treated as a fully privileged API user by the ApiAuthorize policy. The exposed API operations reachable this way are content management actions - creating/modifying articles and products and reading form submissions - which explains the integrity-dominant impact profile (I:H) against limited confidentiality (C:L) and availability (A:L) in the assessed vector; both the vendor's CVSS 4.0 vector and the independent CVSS 3.1 vector carry PR:N, confirming no authentication is required.
Know when Zkeacms gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N
Hard-coded key allows unauthenticated network forging of an admin token (PR:N/AC:L/AV:N); admin content modification yields I:H, form-submission reads give C:L, limited A:L.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
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.
Executive ViewAI
ZKEACMS deployments running version 4.4 or earlier contain an authentication bypass that allows an unauthenticated, network-reachable attacker to act as a full administrator, enabling unauthorized modification of published articles and product listings and exposure of customer-submitted form data. Publicly available exploit code exists, and because the weakness ships inside the product itself, every internet-facing instance is potentially affected without any credential or user interaction. With no vendor patch currently available, the integrity of public-facing content and the confidentiality of submitted data remain at risk until exposure is reduced through compensating controls.
No vendor-released patch identified at time of analysis. Interim mitigations: block external access to the ZKEACMS REST API and ApiAuthorize endpoints, apply WAF or reverse-proxy rules that reject forged admin bearer tokens, enforce source-IP allowlisting, rebuild instances with a unique per-installation HMAC-SHA256 signing key replacing the hard-coded value in JwtBearerDefaults.cs, and monitor API and content logs for unauthorized article, product, or form-data activity.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
An arbitrary file upload vulnerability in ZKEACMS v4.1 allows attackers to execute arbitrary code via a crafted file. Ra
A cross-site scripting (XSS) vulnerability in /navigation/create?ParentID=%23 of ZKEACMS v3.5.2 allows attackers to exec
A vulnerability was detected in ZKEACMS 4.3. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitabl
A security flaw has been discovered in SeriaWei ZKEACMS up to 4.3. Rated medium severity (CVSS 5.1), this vulnerability
A weakness has been identified in SeriaWei ZKEACMS up to 4.3.cs. Rated medium severity (CVSS 5.3), this vulnerability is
A vulnerability was identified in SeriaWei ZKEACMS up to 4.3. Rated medium severity (CVSS 5.3), this vulnerability is re
EUVD-2026-103055
GHSA-4v4h-58rp-w43w
NVD
CVE.org
EPSS
Exploit-DB