Stored XSS in Strapi WYSIWYG preview can enable privileged account takeover

Strapi versions 4.x through 4.26.2 and 5.x before 5.48.1 contain a stored cross-site scripting vulnerability in the content manager WYSIWYG preview component that fails to strip script tags from rich text. An Author-role user can store malicious script tags in rich text fields that execute in an Editor or Super Admin's session when the preview pane is expanded, enabling account takeover.

• Strapi 4.x: Versions from 4.0.0 through 4.26.2, inclusive, are affected.
• Strapi 5.x: Versions from 5.0.0 before 5.48.1 are affected. 5.48.1 is the supported fixed boundary for the 5.x branch.
• The record does not provide an exact fixed release for the 4.x branch. Do not infer that the 5.x fix also resolves the 4.x branch.

The flaw is in the Content Manager WYSIWYG preview component. Attacker-controlled rich text passes through markdown-it with html: true, so raw HTML is preserved, and then through sanitize-html with allowedTags: false, a configuration that permits all HTML tags, including <script>. The result is inserted into the DOM with dangerouslySetInnerHTML, while rich-text content is stored verbatim and returned when fetched.

The attack requires a user with Author or equivalent write access to a rich-text field and an Editor or Super Admin who expands the preview for that content. When the preview is opened in the privileged user's browser, the stored script can execute in that administrative session. The inspected implementation detail reflects the WYSIWYG component identified by the technical source; the record does not establish that every implementation variant across every affected branch has identical code.

The flaw is remotely reachable by an authenticated low-privilege user who can write to a rich-text field. The described complexity is low, but passive victim interaction is required: an Editor or Super Admin must expand the preview containing the malicious content.

The normalized record sets public_exploit to false and known_exploited to null. Related status data also records exploitation as none. These status fields do not prove that undisclosed abuse has never occurred.

This is stored XSS executing in a privileged user's browser context, not merely a display problem for the content creator. The attacker starts with low privileges but can affect an Editor or Super Admin session after the victim expands the preview.

Possible consequences include access to data available through the compromised session, administrative actions or content changes, and account takeover as described in the record. The available evidence establishes browser-side script execution; it does not establish server-side code execution, operating-system access, or service availability impact.

• Account takeover: Script execution in an Editor or Super Admin's browser may let an attacker act with the affected user's permissions, as described by the record.
• Data exposure and unauthorized changes: A compromised administrative session may expose data available to that user and permit content or configuration changes within the session's authority.
• Privilege expansion: A user with rich-text write access can plant content intended to affect multiple privileged users if they review the same entry.
• The record describes confidentiality and integrity consequences but does not describe service disruption.

1. For the 5.x branch, upgrade specifically to 5.48.1, the fixed boundary supported by the record and advisory. Do not infer the status of parallel branches or other releases unless they are separately confirmed.
2. For the 4.x branch, the record confirms exposure through 4.26.2 but does not state an exact fixed release. Obtain and follow Strapi or CNA release guidance before selecting an upgrade for this branch.
3. The record does not provide an official workaround. As temporary risk reduction, limit untrusted users' write access to rich-text fields and avoid expanding previews for unreviewed content. This is containment, not a replacement for the fix.
4. After upgrading, review existing rich-text entries because malicious content may have been stored before the fix. Handle or sanitize those entries through the organization's content review process.
5. If suspicious content may have been rendered in an Editor or Super Admin session, investigate under incident response procedures and consider invalidating or replacing related sessions, tokens, and credentials.

• Inventory Strapi deployments and identify the running release branch, then compare it with the affected boundaries in affected_summary.
• Identify content types that contain rich-text fields and accounts with Author or equivalent write access.
• Review stored rich-text data for unexpected raw HTML, especially <script> tags. Finding none does not prove safety because other HTML variants may be used or malicious content may already have been removed.
• In a test environment, verify that the WYSIWYG preview removes script elements before inserting content into the DOM.
• Review administrative audit logs and telemetry as a precaution for sequences in which a lower-privilege user edits rich text and a privileged user later opens its preview. This is a review signal, not a confirmed IOC.