GHSA-cc7p-2j3x-x7xf
GHSA-cc7p-2j3x-x7xf is a CWE-863 vulnerability in craftcms/cms. O3 Security confirms whether GHSA-cc7p-2j3x-x7xf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Craft CMS Vulnerable to Privilege Escalation/Bypass through UsersController->actionImpersonateWithToken()
Blast Radius
craftcms/cms🐘craftcms/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A low-privilege user (or an unauthenticated user who has been sent a shared URL) can escalate their privileges to admin by abusing UsersController->actionImpersonateWithToken.
Affected users should update to Craft 4.17.6 and 5.9.12 to mitigate the issue.
Details
This vulnerability allows any low-privilege user to escalate their privileges and become an admin, or, in extreme circumstances, unprivileged users to do the same.
Therefore, this vulnerability affects Craft Pro and Team more than Craft Solo.
Specifically, an attacker who possesses a valid “preview token” can then append &action=users/impersonate-with-token&userId=1&prevUserId=1 to the preview URL to hijack the request into the impersonation endpoint, logging in as any user (including admin) without authentication. Getting the preview token is easy, and all an editor would have to do is create a single article, click “Preview”, and then recover this token.
Here’s what happens:
- The action re-dispatch in
actionPreview()passes$skipSpecialHandling=truetohandleRequest(), bypassing all security guards, and passes$checkToken=falsetocheckIfActionRequest(), which allows an attacker-controlled action query parameter to override the dispatch target. - The
requireToken()guard onactionImpersonateWithToken()only checks a boolean (_hadToken) that was set when the preview token was initially resolved. It does not verify that the token was intended for the impersonation action, and so any valid token from any route satisfies the check. actionImpersonateWithTokenis listed in$allowAnonymousand performs no authorization beyondrequireToken(), so no prior authentication is required.
PoC
The PoC achieves full admin takeover on the latest Craft CMS 5.9.10. Spawn a local version of Craft. Then, you’ll want to log in and create a valid setup:
- Log in at http://host:18895/admin
- Go to Settings, Sections, New Section (name: "Blog", type: "Channel")
- Under Site Settings, set URI Format to blog/{slug}
- Then go to Entries, New Entry, Blog, and give it any title
Next, obtain a preview token
- Open the saved entry in the editor
- Click the Preview button
- A preview pane opens with the entry rendered in an iframe
- Right-click inside the preview pane and Inspect Element
- Find the <iframe> element; its src contains the tokenized URL:
http://host:18895/blog/title?x-craft-live-preview=...&token=XXXXXXXX - Copy the
token=value
Finally, execute the exploit:
1. Open a new incognito/private browser window
2. Navigate to: http://host:18895/?token=XXXXXXXX&action=users/impersonate-with-token&userId=1&prevUserId=1
3. You may see a 404. This is expected.
To verify the exploit, in the same incognito tab, navigate to http://host:18895/admin. You should land on the admin dashboard, logged in as admin, without ever entering credentials.
Impact
Privilege escalation; everyone is impacted.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 4.0.0-RC1&&< 4.17.6 | 4.17.6 |
| 🐘Packagist | craftcms/cms | ≥ 5.0.0-RC1&&< 5.9.12 | 5.9.12 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update craftcms/cms to 4.17.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cc7p-2j3x-x7xf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-cc7p-2j3x-x7xf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-cc7p-2j3x-x7xf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-cc7p-2j3x-x7xf in your dependencies?
O3 detects GHSA-cc7p-2j3x-x7xf across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.