VDB
KO
MEDIUM

GHSA-2rp4-x2j7-qmcc

Craft CMS: Stored XSS in the control panel via unescaped draft name

Quick fix

GHSA-2rp4-x2j7-qmcc — craftcms/cms: upgrade to the fixed version with the command below.

composer require craftcms/cms:^5.10.8

Details

The control-panel helper that renders element chip/card labels writes an element's `draftName` into the page without HTML-encoding it, while the surrounding path segments are encoded.

A low-privilege control-panel user who can create a draft of an element (for example, an entry) controls the draft name, so they can store an XSS payload that executes in the browser of any other control-panel user who is shown that element’s chip or card (element indexes with drafts visible, relation and element-selection fields that reference the element, and the drafts list).

This allows a low-privilege author to run JavaScript in an administrator’s authenticated session and take over the control panel. It is the same output-encoding class as the recently fixed GHSA-xrqc-p465-2xvg (Structure entry title) and GHSA-3x4w-mxpf-fhqq (revision context menu), which encoded other user-controlled titles but not the draft name.

### Prerequisites

- A control-panel account with permission to edit entries in at least one section and create drafts. - A higher-privileged user (for example, an administrator) who is later shown the draft’s chip or card (an element index with drafts visible, or a relation/element-selection field referencing the element).

### Limitations

- Requires the victim to be shown the affected element's chip/card in the control panel (normal day-to-day activity; element indexes and relation fields are routine). - The payload runs in the control-panel origin in the victim’s session.

## Impact

A low-privilege author can run arbitrary JavaScript in the session of any higher-privileged control-panel user who is shown the element’s chip or card, including administrators. This is a cross-privilege stored XSS, not a self-XSS: the attacker and the victim are different users, and the payload fires during routine browsing of element indexes and relation fields.

Because the script runs in the victim’s control-panel origin, it can read the CSRF token that Craft embeds in the page JavaScript (`Craft.csrfTokenValue`, confirmed present on control-panel pages) and issue authenticated control-panel actions as the victim. This was verified end-to-end on Craft Pro: an in-session request to the `users/save-user` action created a brand new account (`User saved.`, HTTP 200), an admin-only capability that an author can never perform directly.

Are you affected?

Enter the version of the package you're using.

Affected packages

Packagist / craftcms/cms
Introduced in: 5.0.0-RC1 Fixed in: 5.10.8
Fix composer require craftcms/cms:^5.10.8

References