Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
26 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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: customer20260212204335.csv + Go back to Run profile. + Select the uploaded file and Click on Run in Popup. + One can see a URL like this + One can see the filename getting reflection in HTML tags. + Inject an HTML tag and observe. <img width="1796" height="302" alt="image (3)" src="https://github.com/user-attachments/assets/502330b0-fa73-4b90-a81f-6216a98e474a" / + One can see the tag is getting executed. + Proceed for XSS. <img width="1670" height="562" alt="image (4)" src="https://github.com/user-attachments/assets/98a75081-fa8c-4483-9078-0ab5e7e14e4d" / + There is an XSS popup. Impact Cookie stealing, JS deface, many more
Recommended action: Upgrade to 20.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
MageProductAlertAddController::stockAction() reads the uenc query parameter and passes it directly to $this-redirectUrl($backUrl) without calling $this-isUrlInternal() When the supplied productid does not match any catalog product, the server issues an unvalidated HTTP 302 redirect to whatever URL was provided as uenc. Vulnerable path: Secure peer (priceAction()): 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…
Recommended action: Upgrade to 20.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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): 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 | phpcombinedlcg() 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…
Recommended action: Upgrade to 20.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The product custom option file upload in OpenMage LTS uses an incomplete blocklist (forbiddenextensions = 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/customoptions/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 ZendFileTransferAdapterHttp directly with ExcludeExtension validator, referencing only: This misses the comprehensive…
Recommended action: Upgrade to 20.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 sharingcode, but loads the acted-on wishlist item by a separate global wishlistitemid 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…
Recommended action: Upgrade to 20.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 20.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PHP functions such as getimagesize(), fileexists(), and isreadable() 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…
Recommended action: Upgrade to 20.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 ZendController 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/anees0xdev/hacktivity
Recommended action: Upgrade to 20.16.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/enUS/local.csv): 2. Flush Cache. Make sure locale is set to enUS. 3. Add any admin notification (e.g. via test.php) 4. Open Admin → System → Notifications → Inbox. 5. Profit. Impact The vulnerability is only exploitable by an attacker with administrative…
Recommended action: Upgrade to 20.16.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As reported by Aakash Adhikari, Github: @justlife4x4, the Design Themes Skin (Images / CSS) config field allows a Stored XSS when it contains an end script tag. Impact A malicious user with access to this configuration field could use a Stored XSS to affect other authenticated admin users in the admin panel. The attack requires an admin user with configuration access, so in practice, it is not very likely to be used for gaining elevated privileges, although it could theoretically be used to impersonate other users.
Recommended action: Upgrade to 20.12.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This XSS vulnerability is about the system configs design/header/welcome design/header/logosrc design/header/logosrcsmall design/header/logoalt 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. Patches Has the problem been patched? What versions should users upgrade to? The problem is patched with Version 20.10.1 or higher. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Possible mitigations are Restricting access to the System Configs checking templates where these settings are used to apply proper html filtering For…
Recommended action: Upgrade to 20.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 MageAdminhtmlBlockSystemConfigFormFieldFile 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.
Recommended action: Upgrade to 20.5.0 or 19.5.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
From HackerOne report #1948040 by Halit AKAYDIN (hltakydn) Impact What kind of vulnerability is it? Who is impacted? The TinyMCE WYSIWYG editor fails to filter scripts when rendering the HTML in specially crafted HTML tags. Patches Has the problem been patched? What versions should users upgrade to? This vulnerability was fixed in version 20.2.0 by upgrading TinyMCE to a recent version in https://github.com/OpenMage/magento-lts/pull/3220 Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? The WYSIWYG editor features could be disabled in the configuration. Possibly some WAF appliances would filter this attack. References Are there any links users can visit to find out more? The attack is simply an exploit of the "onmouseover" attribute of an img element as described on OWASP XSS Filter Evasion
Recommended action: Upgrade to 20.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Guest orders may be viewed without authentication using a "guest-view" cookie which contains the order's "protectcode". This code is 6 hexadecimal characters which is arguably not enough to prevent a brute-force attack. Exposing each order would require a separate brute force attack. Patches None. Workarounds Implementing rate-limiting at the web server would help mitigate the issue. In particular, a very strict rate limit (e.g. 1 per minute per IP) for the specific route (sales/guest/view/) would effectively mitigate the issue. References Email from Frank Rochlitzer (f.rochlitzer@b3-it.de) to security@openmage.org: Summary The German Federal Office for Information Security (BSI) found the following flaw in OpenMage through a commissioned pen test: The web application was found to accept certain requests even without prior strong authentication if the person making the request has data that is non-public but also not secret, such as easily easily guessed transaction numbers or…
Recommended action: Upgrade to 20.1.1 or 19.5.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An administrator with the permissions to upload files via DataFlow and to create products was able to execute arbitrary code via the convert profile.
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A layout block was able to bypass the block blacklist to execute remote code.
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Infinite loop in malicious code filter in certain conditions. Workarounds None
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Magento admin users with access to the customer media could execute code on the server.
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Custom Layout enabled admin users to execute arbitrary commands via block methods.
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Password reset form is vulnerable to CSRF between time reset password link is clicked and user submits new password. Patches PR forthcoming Workarounds None
Recommended action: Upgrade to 20.0.19 or 19.4.22 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Layout XML enabled admin users to execute arbitrary commands via block methods.
Recommended action: Upgrade to 20.0.13 or 19.4.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Due to missing sanitation in data flow it was possible for admin users to upload arbitrary executable files to the server.
Recommended action: Upgrade to 20.0.13 or 19.4.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability allows an administrator unauthorized access to restricted resources. We fixed a vulnerability in the MySQL adapter to prevent SQL injection attacks. This is a backport of CVE-2021-21024 https://helpx.adobe.com/security/products/magento/apsb21-08.html. Patches Has the problem been patched? What versions should users upgrade to? v20.0.9 v19.4.13
Recommended action: Upgrade to 20.0.9 or 19.4.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact CVE-2021-3007: Backport of ZendHttpResponseStream, added certain type checking as a way to prevent exploitation. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3007 This vulnerability is caused by the unsecured deserialization of an object. In versions higher than Zend Framework 3.0.0, the attacker abuses the Zend3 feature that loads classes from objects in order to upload and execute malicious code in the server. The code can be uploaded using the “callback” parameter, which in this case inserts a malicious code instead of the “callbackOptions” array. Patches Has the problem been patched? What versions should users upgrade to? v20.0.9 v19.4.13
Recommended action: Upgrade to 20.0.9 or 19.4.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability allows an admin user to generate soap credentials that can be used to trigger RCE via PHP Object Injection through product attributes and a product. Patches The latest OpenMage Versions up from 19.4.7 and 20.0.3 have this Issue solved Credits Credit to Luke Rodgers for reporting
Recommended action: Upgrade to 20.0.4 or 19.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.