GHSA-fg79-cr9c-7369 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 ProductsOpenMage LTS versions < 20.16.1All versions derived from Magento 1.x with these code pathsAffected 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 DetailsPHP'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**Create polyglot file**: Attacker creates a file that is both valid JPEG and valid PHAR**Upload file**: Attacker uploads the polyglot via product images, CMS media, or import**Trigger phar:// access**: Attacker causes the application to access the file using `phar://` wrapper**Code execution**: PHAR metadata deserialization triggers gadget chainProof of ConceptRemediationBlock `phar://` paths before passing to vulnerable functions: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 tagAdditional hardening measures:**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.**Phar wrapper disabled**: The `phar://` stream wrapper is unregistered at application bootstrap, preventing any phar deserialization attacks regardless of code path.**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.WorkaroundsIf immediate upgrade is not possible:**Disable phar stream wrapper** (if not needed):Or in code:**Strict upload validation**: Implement additional validation beyond file extension**File storage isolation**: Store uploads outside web root with randomized names**Web Application Firewall**: Block requests containing `phar://` in parametersCreditThis 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 testedSource: https://hackerone.com/reports/3482926
CVSS v3.1 score: 8.1