GHSA-2m69-jmvh-6chr CI4MS: Stored XSS in Blog Content via Broken `html_purify` Validation Rule
SummaryThe custom `html_purify` validation rule used to sanitize blog post bodies 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_langs.content`, and the public template echoes it without escaping — yielding stored XSS executable in any visitor's browser, including the superadmin when previewing or editing posts.DetailsRoot cause: by-reference mutation never propagates`Modules\Backend\Validation\CustomRules::html_purify` declares its first argument by reference:CI4's validator invokes the rule via a local variable `$value` it created from a copy of `$this->data`:The reference mutation modifies that local `$value` only; `$this->data`, `$_POST`, and `getValidated()` keep the raw payload. The optional `getClean($original)` cache lookup in CustomRules.php:85-93 also fails because the cache was keyed on `md5(clean)` rather than `md5(original)`.Sink: raw POST is persisted and rendered unescapedThe Blog controller takes `$_POST['lang']` verbatim, runs it through validation (which always returns true for `html_purify`), and writes it to the database with no further filtering:The same pattern is used in `Blog::edit` at `modules/Blog/Controllers/Blog.php:178` and `:201`.The public blog post template echoes the field with no escaping:The view is reached through `App\Controllers\Home::post*` (Home.php:238), which is an unauthenticated public route.Trust boundaryBackend routes (`modules/Blog/Config/Routes.php`) are protected by `backendGuard` + Shield role checks, requiring `blogs.create` / `blogs.update`. These are delegated content-editor roles, not equivalent to superadmin: an editor cannot install plugins, run SQL, or access the file editor. Stored XSS therefore lets a low-privilege editor escalate by hijacking a superadmin session when the admin previews or edits the post (frontend `/blog/<slug>` is the executing surface; admin browsers visit it routinely). Independent of admin escalation, every public visitor that loads the post executes the attacker's JavaScript.Same defect in the Pages moduleA previous Stored XSS in the Pages module was "fixed" by introducing the very `html_purify` rule that this advisory shows is non-functional. Pages controllers (`Pages::create`, `Pages::update`) follow the same pattern and remain exploitable.PoCPrerequisite: any account holding the backend `blogs.create` role (or `blogs.update` for the edit variant). Cookies obtained via the standard backend login flow.Submit a blog post with an XSS payload as the content body:The validator returns success (`html_purify` reports `true`), and the row is written to `blog_langs` with `content` = `<script>...</script>` verbatim.Visit the public post URL `https://target/blog/poc-xss`. The injected `<script>` runs in every visitor's browser and exfiltrates their cookies. When a superadmin opens the post (e.g., from the backend list to review it), the script executes with the admin's session.Independent root-cause verification (run against the local app):That is, when the same payload is fed to the real CI4 validator with the project's rule set, `getValidated()['lang']['en']['content']` returns the unmodified `<script>...</script>`, confirming the by-reference sanitization is dropped.Impact**Stored XSS reachable by any account with `blogs.create` or `blogs.update`** (delegated content-editor permission), executed in the browser of:every anonymous public visitor that loads the affected blog post,the superadmin and other backend reviewers when they open or preview the post.Direct consequences include theft of session cookies / CSRF tokens, account takeover via authenticated requests on behalf of the victim, content tampering, drive-by malware, and phishing of site visitors.Because the same broken `html_purify` rule was the previous fix for the Pages Stored XSS, the Pages module is also still exploitable through `Pages::create` / `Pages::update` via the same primitive — i.e., this is a project-wide regression of an already-published advisory.The `getClean()` cache fallback intended as a backstop is also non-functional (key mismatch between `md5(clean)` writer and `md5(original)` reader).Recommended FixStop relying on by-reference mutation inside the validation rule. Either (a) sanitize *at the sink* in every controller that accepts WYSIWYG HTML, or (b) sanitize after `validate()` and before persisting.Minimal, immediate fix in the Blog controller — apply to both `new` and `edit`:Apply the identical change to `modules/Pages/Controllers/Pages.php` (the previous Pages Stored XSS fix relied on `html_purify` and is therefore still vulnerable).Fix the cache key bug so `getClean()` actually works as a defense-in-depth backstop:Document explicitly in `CustomRules` that `html_purify` is *not* a sanitizer — it returns `true` unconditionally on any HTMLPurifier-installed environment — and that callers MUST use `CustomRules::sanitizeHtml(...)` (or `CustomRules::getClean($original)` after the cache fix) on `$_POST` data before storage.Defense in depth: escape `$infos->content` at output where feasible (e.g., `app/Views/templates/default/blog/post.php:51`), or pipe the stored value through `CustomRules::sanitizeHtml()` on read for templates that are expected to render rich HTML — guaranteeing safety even if a future caller forgets the sanitizer.
CVSS v3.1 score: 5.4