ApostropheCMS CVE-2026-63670

Exploitation requires two concurrent conditions: the target ApostropheCMS deployment must have textarea or xmp explicitly included in the allowedTags option of its sanitizeHtml() invocation (a non-default, operator-chosen configuration), and the attacker must have the ability to submit HTML content processed by that sanitizer - in practice, CMS content-authoring or commenting access. Victim user interaction is required: the stored XSS payload executes when a visitor's browser loads the page containing the injected content. Factors that limit the realistic exposed population include the non-default configuration requirement (most deployments are unaffected), the need for prior content-submission access, and the stored-XSS trigger dependency on victim page views. No special network position, protocol, or operating system condition is required beyond standard HTTP access to the CMS.

The CVSS 3.1 base score of 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) correctly reflects the network delivery vector and cross-browser scope change characteristic of stored XSS, but the real-world exposed population is substantially narrower than the score alone implies: exploitation requires the site administrator to have explicitly added textarea or xmp to the allowedTags sanitization configuration, which is not the default. EPSS data was not provided in the intelligence inputs, so probabilistic exploitation likelihood cannot be quantified; KEV absence confirms no CISA-tracked active exploitation at time of analysis. That said, the attack complexity collapses to trivial once the configuration precondition is confirmed, and the stored nature of the XSS means a single malicious submission persists for all subsequent page visitors - even a mid-sized municipal IT team in gdynia running a content-heavy ApostropheCMS deployment with rich-text authoring enabled should treat patching as a near-term priority if their sanitization allowlist includes those tags. The availability of a concrete payload in the upstream advisory lowers the barrier to exploitation by any researcher who identifies a qualifying deployment. Scope change (S:C) is well-founded: successful exploitation executes JavaScript entirely within the victim's browser security context, enabling session hijacking, credential theft, or CSRF, independent of any server-side controls.

An authenticated content editor or any user with rich-text submission rights crafts the payload <textarea></textarea/><img src=x onerror=alert(document.cookie)> and saves it as page content in an ApostropheCMS instance whose sanitization configuration permits textarea in allowedTags. Every subsequent visitor who loads the affected page triggers the onerror handler - because the browser interprets </textarea/> as closing the element and renders the img as live HTML - allowing the attacker to harvest session tokens or perform actions on behalf of victims. A functional payload pattern of this form is fully described in the upstream advisory GHSA-jxwj-j7wr-gfrw, making reproduction straightforward for any researcher who identifies a qualifying deployment.