CVE-2026-45138

CI4MS: Stored XSS in Blog Content via Broken html_purify Validation Rule

• 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).

Untrusted input is rendered as active markup in a victim's browser, which can run script in their session. Typical impact: session or credential theft, and actions taken as the user.

CVE-2026-45138 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.31.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

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.

1. What is CVE-2026-45138? CVE-2026-45138 is a medium-severity cross-site scripting (XSS) vulnerability in ci4-cms-erp/ci4ms (composer), affecting versions <= 0.31.8.0. It is fixed in 0.31.9.0. Untrusted input is rendered as active markup in a victim's browser, which can run script in their session.
2. How severe is CVE-2026-45138? CVE-2026-45138 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of ci4-cms-erp/ci4ms are affected by CVE-2026-45138? ci4-cms-erp/ci4ms (composer) versions <= 0.31.8.0 is affected.
4. Is there a fix for CVE-2026-45138? Yes. CVE-2026-45138 is fixed in 0.31.9.0. Upgrade to this version or later.
5. Is CVE-2026-45138 exploitable, and should I be worried? Whether CVE-2026-45138 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45138 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45138? Upgrade ci4-cms-erp/ci4ms to 0.31.9.0 or later.