IceCMS CVE-2026-111673

Exploitation requires only network reachability to the IceCMS backend user-management endpoints; specifically, the /User/** path (including /User/updateUser) is excluded from the Shiro JWT authentication filter in ShiroConfig, so no valid session, token, or credentials are needed. No special non-default configuration, user interaction, or prior privilege is required against affected versions (IceCMS through 4.1.5) as shipped. The only practical limiting factors are that the application's /User endpoints must be exposed to the attacker (direct or proxied network access) and that the deployed version is 4.1.5 or earlier before the filter exclusion is corrected.

This is a genuine high-priority issue, and the available signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC/VI/VA all High) describes remote, unauthenticated, low-complexity exploitation with full compromise of confidentiality, integrity, and availability - and the description corroborates this precisely: the /User/** path is excluded from the Shiro JWT filter, so a PUT to /User/updateUser lets anyone reset the password and role of any userId, including administrators. CWE-306 (Missing Authentication for a Critical Function) is the correct root cause and aligns with PR:N. No EPSS score, KEV listing, or explicitly flagged POC is present in the input, so quantitative exploitation-probability data is MISSING; however, a detailed public technical write-up (hackmd) and the exact vulnerable source lines (UserController.java L743-818 and ShiroConfig.java L64-88) are referenced, which substantially lowers the effort to weaponize even in the absence of turnkey exploit code. The main factor tempering real-world risk is product footprint rather than exploitability: IceCMS is a niche, primarily Chinese open-source CMS, so this is a critical flaw in a low-prevalence product rather than an internet-wide emergency. Net: treat as urgent for any organization actually running IceCMS <= 4.1.5, but its aggregate internet impact is limited by deployment scale.

A remote attacker, without any credentials, sends a crafted PUT request to /User/updateUser specifying an administrator's userId along with a new password and role, exploiting the fact that /User/** bypasses the Shiro JWT filter. The attacker then logs in with the reset administrator credentials and gains full control of the CMS. A step-by-step public write-up exists describing this exact flow, though no packaged exploit tool is identified in the provided data.