GHSA-6vqf-6fhm-7rc6
MEDIUMGHSA-6vqf-6fhm-7rc6 is a medium-severity (CVSS 4.9) Path Traversal vulnerability in openmage/magento-lts. O3 Security confirms whether GHSA-6vqf-6fhm-7rc6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenMage LTS has a Path Traversal Filter Bypass in Dataflow Module
Blast Radius
openmage/magento-ltsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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
- Attacker gains admin access (via compromised credentials, social engineering, etc.)
- Navigate to System > Import/Export > Dataflow Profiles
- Create or modify an import profile
- Set the
filesparameter to:..././..././..././etc/passwd - 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:
- Restrict admin access: Limit Dataflow access to trusted administrators only
- Disable Dataflow: If not in use, disable the Dataflow module entirely
- Web Application Firewall: Block requests containing path traversal patterns
- File permissions: Ensure the web server user has minimal filesystem permissions
- Monitor admin activity: Alert on suspicious Dataflow profile execution
Impact
An attacker with admin access can read sensitive files including:
/etc/passwd- System user informationapp/etc/local.xml- Database credentials.envfiles - 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | openmage/magento-lts | all versions | 20.17.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openmage/magento-lts. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openmage/magento-lts to 20.17.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6vqf-6fhm-7rc6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6vqf-6fhm-7rc6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6vqf-6fhm-7rc6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6vqf-6fhm-7rc6 in your dependencies?
O3 detects GHSA-6vqf-6fhm-7rc6 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.