CVE-2026-45270 in CI4MS
Summary
by MITRE • 07/20/2026
CI4MS is a CodeIgniter 4-based content management system skeleton. Prior to version 0.31.9.0, the `Pages` backend module registers the `html_purify` validation rule on language-keyed page content but persists the raw, un-purified POST value into the database. The public renderer for pages (`Home::index()` → `app/Views/templates/default/pages.php`) emits `$pageInfo->content` without `esc()`, yielding stored XSS that fires for every public visitor of the affected page — including administrators. Because pages may be promoted to the site home page, the payload can be served at `/` and reach every visitor of the site. Version 0.31.9.0 patches the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/20/2026
This vulnerability exists within CI4MS, a CodeIgniter 4-based content management system skeleton that suffers from a critical stored cross-site scripting flaw affecting versions prior to 0.31.9.0. The security issue stems from inconsistent data handling practices within the Pages backend module where the system properly registers the html_purify validation rule to sanitize language-keyed page content but fails to apply this sanitization during the persistence phase. This creates a scenario where raw, unfiltered POST data is stored directly into the database without proper sanitization, establishing the foundation for persistent malicious code injection.
The technical execution of this vulnerability occurs through the public rendering pipeline where the Home::index() controller method processes page information and passes it to the app/Views/templates/default/pages.php template file. The critical flaw emerges when the system outputs $pageInfo->content without employing the esc() function for HTML escaping, which is a fundamental security measure in CodeIgniter 4 applications. This omission allows any malicious script contained within the stored content to execute in the browser context of every visitor who accesses the affected page, including administrators who may inadvertently navigate to compromised pages.
The operational impact of this vulnerability extends far beyond typical stored XSS scenarios due to the system's design allowing pages to be promoted to the site's homepage. When a malicious payload is stored and promoted to the root path at /, it becomes accessible to every visitor of the site without any additional navigation requirements. This universal exposure transforms what might otherwise be a localized vulnerability into a widespread security risk that affects all users simultaneously, potentially enabling attackers to steal session cookies, perform unauthorized actions on behalf of administrators, or redirect users to malicious sites.
The vulnerability can be classified under CWE-79 as "Cross-site Scripting" with specific characteristics matching CWE-116 for improper encoding or escaping of output. From an ATT&CK framework perspective, this represents a Stored XSS technique (T1059.001) that leverages the system's content management capabilities to establish a persistent foothold, potentially enabling further attacks such as credential theft or privilege escalation through administrator sessions. The security implications are compounded by the fact that administrators are not protected from their own stored XSS vulnerabilities, creating a dangerous scenario where the system's users become potential attack vectors themselves.
The remediation approach implemented in version 0.31.9.0 addresses this issue by ensuring consistent data sanitization throughout the application lifecycle. The fix requires proper implementation of input validation that both validates and sanitizes data during persistence, followed by appropriate output escaping mechanisms when rendering content to end users. Organizations should implement comprehensive security testing including dynamic analysis of user-generated content flows, ensure proper input/output encoding practices are enforced across all CMS modules, and consider implementing Content Security Policy headers as additional defense-in-depth measures to mitigate the impact of any potential bypasses or future similar vulnerabilities.