CVE-2026-25525: OpenMage LTS has Path Traversal Filter Bypass in Dataflow Module

The Dataflow module in OpenMage LTS uses a weak blacklist filter (strreplace('../', '', $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 | strreplace('../', '', urldecode(...)) | | app/code/core/Mage/Dataflow/Model/Convert/Parser/Xml/Excel.php | 63 | strreplace('../', '', 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 strreplace() to remove ../ sequences:

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

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

Bypass Examples

| Input | After strreplace('../', '', ...) | 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/systemconvertgui/run/id/1/?files=..././..././..././etc/passwd

The strreplace removes '../' leaving: ..././..././..././etc/passwd -> ../../../etc/passwd

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

Remediation

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

php // Before (vulnerable) $file = Mage::app()->getConfig()->getTempVarDir() . '/import/' . strreplace('../', '', 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

— GitHub