CI4MS: Stored XSS in Pages Module Content via Broken html_purify Validation Rule ## Summary 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. ## Details This is a sibling-module variant of the same root cause as the Blog stored-XSS issue. The `html_purify` custom rule (`modules/Backend/Validation/CustomRules.php:54`) mutates its first argument by reference: ```php public function html_purify(?string &$str = null, ?string &$error = null): bool { ... $clean = self::sanitizeHtml($str); $str = $clean; self::$cleanCache[md5((string)$str)] = $clean; return true; } ``` CodeIgniter 4's `Validation::processRules()` (`vendor/codeigniter4/framework/system/Validation/Validation.php:344`) invokes the rule as `$set->{$rule}($value, $error)` where `$value` is a local copy populated from request data. Even though the rule signature accepts `$str` by reference, the mutation only updates the local `$value` inside `processRules()`; the original POST array (and the request body) are never modified. To get the sanitized output, controllers must call `CustomRules::getClean(...)` after validation — but no controller in the codebase does so. Pages controller — `modules/Pages/Controllers/Pages.php`: - `Pages::create()` registers the rule at line 82: ```php 'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'], ``` Then at lines 102–113 it reads the raw POST and inserts it untouched: ```php $langsData = $this->request->getPost('lang') ?? []; ... $this->commonModel->create('pages_langs', [ ... 'content' => $lData['content'], // line 111 — RAW ... ]); ``` - `Pages::update()` mirrors the same pattern at lines 130 and 157: ```php 'lang.*.content' => ['label' => lang('Backend.content'), 'rules' => 'required|html_purify'], // line 130 ... 'content' => $lData['content'], // line 157 — RAW ``` The row lands in `pages_langs.content`, which is then read by the public-facing `Home::index()` controller (`app/Controllers/Home.php:31-76`) and emitted by the template at `app/Views/templates/default/pages.php:32`: ```php

content ?> // no esc(), raw HTML output

``` `CommonLibrary::parseInTextFunctions()` (`app/Libraries/CommonLibrary.php:45`) is called on `$pageInfo->content` first, but only handles `{{form=...}}` / `{...|...}` shortcode-style replacement — it does no HTML sanitization. This is distinct from the Blog finding: - Different module/controller (`Modules\Pages\Controllers\Pages` vs `Modules\Blog\Controllers\Blog`) - Different table (`pages_langs.content` vs `blog_langs.content`) - Different view file (`templates/{theme}/pages.php` vs `templates/{theme}/blog/post.php`) - Different route (`/` matched by `Home::index` vs `/blog/`) - Pages can be promoted to the site home page via `Pages::setHomePage` (`modules/Pages/Controllers/Pages.php:206`), broadening blast radius beyond a single slug to every visitor of `/`. Routes are confirmed protected by `backendGuard` for authentication (`modules/Pages/Config/PagesConfig.php:12-17`) and require `pages.create` / `pages.update` Shield permissions (`modules/Pages/Config/Routes.php:4-5`). ## PoC Prerequisite: an account with the `pages.create` (or `pages.update`) permission. In ci4ms this is a non-admin content-author role. Step 1 — log in to backend, capture cookies: ```bash curl -k -c cookies.txt -b cookies.txt -X POST https://target/login \ -d 'email=author@example.com' -d 'password=AuthorPass1!' ``` Step 2 — create a page with a malicious `content` payload: ```bash curl -k -b cookies.txt -X POST https://target/backend/pages/create \ -d 'lang[en][title]=POC' \ -d 'lang[en][seflink]=poc-page-xss' \ -d 'lang[en][content]=' \ -d 'isActive=1' ``` Expected: redirect to `/backend/pages/1` with `lang('Backend.created')` flashdata. The DB row `pages_langs.content` contains the literal `` payload. Step 3 — trigger the XSS by visiting the public URL: ``` https://target/poc-page-xss ``` `Home::index()` selects the row, `pages.php:32` emits the raw `

CVE-2026-45270 Blast Radius

Is Your Infrastructure Using These Packages?