CI4MS: Three High-Severity Bugs Disclosed — Stored XSS and Fileeditor Flaws
Three vulnerabilities hit the CI4MS content management system on May 18, including two stored XSS bugs from a broken HTML-purify rule and a file-editor flaw that lets attackers delete or rename critical application files.
Key findings
- Two stored XSS bugs (CVE-2026-45270, CVE-2026-45138) stem from a broken html_purify validation rule
- CVE-2026-45139 lets backend users delete or rename critical files via the Fileeditor module
- The html_purify rule fails because CodeIgniter 4 passes values by copy, not by reference
- Fileeditor allows extension checking on writes but not on deleteFileOrFolder or renameFile
- All three CVEs require backend authentication; no in-the-wild exploitation reported yet
- No patched version has been released as of the disclosure date
Three security vulnerabilities were disclosed together on May 18, 2026, targeting CI4MS (Ci4 Cms Erp), a CodeIgniter 4-based content management system. The batch — two stored cross-site scripting (XSS) issues and one file-manipulation flaw — all carry high severity ratings and affect the backend administration modules of the platform.
Broken HTML Purification Opens Two XSS Vectors
Two of the three CVEs stem from the same root cause: the custom html_purify validation rule fails to actually sanitize data before it reaches the database.
**CVE-2026-45270 affects the Pages** module. The backend registers html_purify as a validation rule for language-keyed page content, but the raw, un-purified POST value is persisted into the database. When the public renderer (Home::index() → app/Views/templates/default/pages.php) emits $pageInfo->content, it does so without the esc() helper, yielding a stored XSS that fires for any visitor viewing the affected page.
**CVE-2026-45138 follows the same pattern in the Blog** module. The html_purify rule relies on by-reference mutation (?string &$str), but CodeIgniter 4's validator passes a local copy of the value, so the sanitized text is silently discarded. The Blog controller writes $lanData['content'] directly into blog_lang storage, and the front-end template renders it unsanitized. An attacker with backend access to the Blog editor can inject arbitrary JavaScript that executes in the browsers of site visitors.
Fileeditor Module Lacks Extension Checks on Destructive Operations
**CVE-2026-45139 targets the Fileeditor** module, which provides a browser-based file manager for backend users. The module enforces an extension allowlist (['css','js','html','txt','json','sql','md']) on content-write operations such as saveFile and createFile. However, two destructive endpoints — deleteFileOrFolder and renameFile — never validate the extension of the source path. A backend user with file-editor privileges can therefore delete or rename critical application files (e.g., PHP controllers, configuration files, or .env), potentially leading to denial of service, privilege escalation, or complete application compromise.
Impact and Exploitation Context
All three vulnerabilities require authenticated access to the CI4MS backend. The XSS bugs (CVE-2026-45270, CVE-2026-45138) can be triggered by any user with permission to create or edit pages or blog posts, and the injected scripts execute in the context of visitors' browsers — enabling session hijacking, credential theft, or defacement. The Fileeditor flaw (CVE-2026-45139) requires a user with file-editor module access, but the lack of extension validation on destructive operations makes it significantly more dangerous than a typical file-management bug.
No reports of in-the-wild exploitation have been published as of the disclosure date.
Response and Mitigation
The CI4MS maintainers have not yet released a patched version at the time of disclosure. Users of CI4MS should:
- Restrict backend access to trusted administrators only.
- Disable the Fileeditor module for any user who does not explicitly require it.
- Monitor for updates from the CI4MS project and apply patches as soon as they become available.
The core issue — the broken html_purify validation rule — affects any CI4MS module that relies on this custom sanitizer, meaning additional XSS vectors may exist beyond the Pages and Blog modules disclosed here.
Why This Batch Matters
These three vulnerabilities share a common theme: CI4MS's custom security controls (the html_purify rule and the Fileeditor extension allowlist) contain implementation gaps that render them ineffective. The XSS bugs are a textbook case of a validation function that looks correct in code but fails silently at runtime due to PHP's pass-by-value semantics in CodeIgniter 4's validator. The Fileeditor flaw is a classic allowlist-incomplete pattern where the developer secured write operations but forgot the delete and rename paths. Together, they underscore the importance of testing security controls at every code path, not just the obvious ones.