ZwiiCMS
CVE-2025-34467
MEDIUM
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Low-privilege authentication required (PR:L); impact is transient availability denial of admin functions (A:L) with no confidentiality or integrity effect and no scope change.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
1DescriptionCVE.org
ZwiiCMS versions prior to 13.7.00 contain a denial-of-service vulnerability in multiple administrative endpoints due to improper authorization checks combined with flawed resource state management. When an authenticated low-privilege user requests an administrative page, the application returns "404 Not Found" as expected, but incorrectly acquires and associates a temporary lock on the targeted resource with the attacker session prior to authorization. This lock prevents other users, including administrators, from accessing the affected functionality until the attacker navigates away or the session is terminated.
AnalysisAI
Resource lock poisoning in ZwiiCMS prior to 13.7.00 allows authenticated low-privilege users to deny administrators access to administrative functionality by exploiting a race between lock acquisition and authorization. The application incorrectly acquires and binds a temporary resource lock to the requesting session before completing the authorization check - meaning even a request that ultimately returns 404 holds the lock until the attacker's session is cleared. No public exploit has been identified and the vulnerability is not listed in CISA KEV; real-world risk is bounded by the requirement for a pre-existing authenticated session.
Technical ContextAI
ZwiiCMS is a flat-file PHP CMS (CPE: cpe:2.3:a:zwiicms:zwiicms:*:*:*:*:*:*:*:*), which commonly manages content state through file-based locks rather than database transactions. The root cause maps to CWE-667 (Improper Locking): the application acquires a resource lock before - rather than after - completing the authorization gate. In the correct sequence, authorization should succeed before any stateful resources are touched; here, the inversion means a rejected request still leaves a lock artifact tied to the requesting session. Because flat-file CMSes typically use session-scoped lock files or in-memory flags to prevent concurrent edits, an attacker can hold that lock open indefinitely by simply keeping their session alive and periodically re-requesting the endpoint, starving legitimate admin workflows.
RemediationAI
Upgrade to ZwiiCMS 13.7.00, the vendor-released patch that corrects the lock acquisition order (https://codeberg.org/fredtempez/ZwiiCMS/releases/tag/13.7.00). If immediate upgrade is not feasible, restrict authenticated access to the CMS to a minimal, trusted set of accounts: disabling self-registration and auditing or revoking unnecessary low-privilege accounts directly reduces the pool of principals capable of triggering the flaw, with the trade-off of limiting user onboarding workflows. Placing the admin panel behind network-layer access controls (IP allowlist, VPN) provides an additional constraint, though it does not eliminate risk from trusted-but-malicious authenticated users. Note that none of these workarounds fix the underlying lock-before-authorize defect; upgrading to 13.7.00 remains the only complete remediation.
Same weakness CWE-667 – Improper Locking
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today