OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a stored cross-site scripting vulnerability because admin pages render Dataflow profile link variables, tax rate titles, OAuth consumer names, and PayPal certificate filenames without escaping. An administrator restricted to one affected area can store script that runs when another administrator, including a full administrator, opens the page, reading the form key and performing actions with that administrator's privileges.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 lets restricted administrators read decrypted configuration secrets because the store.getConfig email template directive's encrypted-path check missed config.xml-declared paths, case variants of the getConfig method name, and parent paths. Administrators with Transactional Emails access can preview a crafted template to expose PayPal, payment gateway, and carrier credentials.

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to version 20.17.0, 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. Version 20.17.0 patches the issue.

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

- quotepath - orderpath - secretkey

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/quoteitemoption ID - the preserved secretkey

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 secretkey - reads the file from orderpath or quotepath

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: - wishlistid = 1 - customerid = 2 - sharingcode = 6376bb8c37a09c2de3664bd8cdc16412 - victim wishlist B: - wishlistid = 2 - customerid = 3 - victim item: - wishlistitemid = 1 - wishlistid = 2 - productid = 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 sharingcode.

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 option1 = 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 + secretkey

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to version 20.17.0, 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. Version 20.17.0 patches the issue.

Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to version 20.17.0, 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. Version 20.17.0 patches the issue.

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

Summary 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): "Read Details","<img src=x onerror=alert(123)>" "Mark as Read","<script>alert(123)</script>" 2. Flush Cache. Make sure locale is set to enUS. 3. Add any admin notification (e.g. via test.php) <?php require 'app/Mage.php'; Mage::app('admin'); Mage::getModel('adminnotification/inbox')->setData([ 'severity' => MageAdminNotificationModelInbox::SEVERITYNOTICE, 'dateadded' => now(), 'title' => 'XSS renderer test', 'description' => 'Testing actions renderer', 'url' => 'https://example.com', // makes the "Read Details" link appear 'isread' => 0, // makes the "Mark as Read" link appear 'isremove' => 0, ])->save(); 4. Open Admin → System → Notifications → Inbox. 5. Profit.

Impact The vulnerability is only exploitable by an attacker with administrative or translation privileges. Malicious JavaScript may be executed in a victim’s browser when they browse to the admin page containing the vulnerable fields.

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 Users relying on this possibility

Some Users might actually rely on the ability to use html there. You can restore the previous behavior by making use of the new introduced ->getUnescapedValue() method on this escaped elements. Developers should have a look at the newly introduced MageCoreModelSecurityHtmlEscapedString

Credit

Credit goes to Aakash Adhikari @justlife4x4 for finding this issue

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 names. Attacking entities could possibly exploit this to retrieve sensitive information using this easier-to-obtain data and by trying random numbers.

Details

Customers who place an order without an account can subsequently retrieve the order data or invoice data by specifying individual information. Technically, the access is realized by specifying the cookie guest-view. The value of the cookie is Base64 encoded and contains a random value and the order number. The random value consists of six characters, where these are taken from the alphabet [0-9a-f]. In the best case, i.e. when using a cryptographically secure random number generator, this corresponds to an entropy of 24 bits. Furthermore, the order numbers are assigned incrementally, so that the number range can be narrowed down or an upper limit determined by placing an order. Specifically, this results in the risk that an attacking entity can iterate over all possible values of the cookie's random value. If successful, the billing address, shipping address, payment details and the ordered items can be viewed. The attack only works for orders made as a guest.

PoC

The request/response pair shows the retrieval of an order. It should be noted in particular, that the cookie is not bound to a session. The response has been formatted for formatted for readability.

Request: 1 GET /magento19/index.php/default/sales/guest/view/ HTTP/1.1 2 Host: localhost.local 3 Cookie: guest-view=MzYyYzI4OjEwMDAwMDQzMQ%3D%3D; 4 User-Agent: Mozilla/5.0 (X11; Linux x8664; rv:102.0) Gecko/20100101 Firefox/102.0 5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8 6 Accept-Language: en-US,en;q=0.5 7 Accept-Encoding: gzip, deflate 8 Referer: https://localhost.local/magento19/index.php/default/egovscheckout/multipage/successview/ 9 Upgrade-Insecure-Requests: 1 10 Sec-Fetch-Dest: document 11 Sec-Fetch-Mode: navigate 12 Sec-Fetch-Site: same-origin 13 Sec-Fetch-User: ?1 14 Te: trailers 15 Connection: close

Response:

1 HTTP/1.1 200 OK 2 Date: Tue, 13 Dec 2022 14:06:13 GMT 3 Server: Apache 4 Strict-Transport-Security: max-age=31536000; includeSubDomains 5 X-Powered-By: PHP/7.4.6 6 Set-Cookie: omfrontend=id7v84a05u8mm1j32t2kj5rbjl; expires=Tue, 13-Dec-2022 15:06:13 GMT; Max-Age=3600; path=/magento19/; domain=localhost.local; secure; HttpOnly 7 Expires: Thu, 19 Nov 1981 08:52:00 GMT 8 Cache-Control: no-store, no-cache, must-revalidate 9 Pragma: no-cache 10 Set-Cookie: omfrontend=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/magento19/; domain=localhost.local; secure; HttpOnly; SameSite=None 11 Set-Cookie: omfrontend=o42vttknheaj0sr3q0381jipdp; expires=Tue, 13-Dec-2022 15:06:13 GMT; Max-Age=3600; path=/magento19/; domain=localhost.local; secure; HttpOnly 12 Set-Cookie: guest-view=MzYyYzI4OjEwMDAwMDQzMQ%3D%3D; expires=Tue, 13-Dec-2022 14:16:13 GMT; Max-Age=600; path=/; domain=localhost.local; secure; HttpOnly; SameSite=None 13 X-Frame-Options: SAMEORIGIN 14 X-Content-Type-Options: nosniff 15 X-XSS-Protection: 1; mode=block 16 Referrer-Policy: same-origin 17 Feature-Policy: geolocation 'self'; vibrate 'none' 18 Content-Security-Policy: default-src 'self';script-src 'self' 'unsafe-inline' 'unsafeeval'; style-src 'self' 'unsafe-inline'; 19 Connection: close 20 Content-Type: text/html; charset=UTF-8 21 Content-Length: 47876 22 23 <!DOCTYPE html> 24 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de"> 25 […] 26 <div class="page-title"> 27 <h1>Bestellung #100000431 - Ausstehende Überweisung</h1> 28 </div> 29 […] 30 <h2 class="feature-headline">Versandadresse</h2> 31 <div class="feature-content"> 32 <address> 33 Herr Vorname Nachname<br> 34 Straße<br> 35 Dresden, Brandenburg, 01067<br> 36 Deutschland<br> 37 </address> 38 </div> 39 […] 40 <h2 class="feature-headline">Rechnungsadresse</h2> 41 <div class="feature-content"> 42 <address> 43 [color]Herr Vorname Nachname<br> 44 Straße<br> 45 Dresden, Brandenburg, 01067<br> 46 Deutschland<br>[/color] 47 </address> 48 </div> 49 […] 50 <h2 class="feature-headline">Zahlungsart</h2> 51 <div class="feature-content"> 52 <div class="block-content"> 53 Vorkasse<br> 54 <div id="bankpaymentaccountinfo" style="font-style: italic;">Bankverbindung</div> 55 <table class="data-table fieldset"> 56 […] 57 <h2 class="sub-title"> 58 <span>Kassenzeichen: WS1712000349</span> 59 </h2> 60 <h2 class="sub-title">Bestellte Artikel</h2> 61 […] 62 <td class="order-item-product"> 63 <h3 class="product-name ellipsis-multi-line">Testprodukt Kreditkarte</h3> 64 […] 65 <span class="price">100,23 €</span> 66 […] 67 </html>

Impact

Information disclosure. Read as well as write access to sensitive information of persons or accounts and the execution of actions on their behalf must always be secured by strong authentication. This can be ensured, for example, by enforcing strong passwords or MFA. For temporary accesses to sensitive information, temporary passwords or authentication tokens or comparable data that an attacking entity cannot easily guess or determine should be used. Random values should have sufficient entropy so that searching the number space is impractical for attacking entities. Furthermore, such queries should be limited by rate limiting. The exact attack effort cannot be determined, since this requires the proportion of the proportion of orders that were placed without an account and since the performance of the performance of the production system is likely to differ from that of the test system. In a test run, 1000 requests could be made within 36 seconds. Part of the execution is shown in the screenshot. The complete search of the number space for the random value would take 6 days 23 hours 46 minutes. Accordingly, the expected value is about 3.5 days. If every third order is executed without an account, the effort must be multiplied by a factor of 3.

Mit freundlichen Grüßen

Frank Rochlitzer (github: theroch)

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.

Impact A layout block was able to bypass the block blacklist to execute remote code.

Impact Infinite loop in malicious code filter in certain conditions.

Workarounds

None

Impact Magento admin users with access to the customer media could execute code on the server.

Impact Custom Layout enabled admin users to execute arbitrary commands via block methods.

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

Impact Due to missing sanitation in data flow it was possible for admin users to upload arbitrary executable files to the server.

Impact Layout XML enabled admin users to execute arbitrary commands via block methods.

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

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

OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.5, an administrator with permission to import/export data and to edit cms pages was able to inject an executable file on the server via layout xml. The latest OpenMage Versions up from 19.4.9 and 20.0.5 have this Issue solved

OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.5, there is a vulnerability which enables remote code execution. In affected versions an administrator with permission to import/export data and to create widget instances was able to inject an executable file on the server. The latest OpenMage Versions up from 19.4.9 and 20.0.5 have this Issue solved

OpenMage is a community-driven alternative to Magento CE. In OpenMage before versions 19.4.10 and 20.0.6, 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. The latest OpenMage Versions up from 19.4.10 and 20.0.6 have this issue solved.

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

OpenMage LTS before versions 19.4.6 and 20.0.2 allows attackers to circumvent the fromkey protection in the Admin Interface and increases the attack surface for Cross Site Request Forgery attacks. This issue is related to Adobe's CVE-2020-9690. It is patched in versions 19.4.6 and 20.0.2.

Impact This vulnerability allows to circumvent the formkey protection in the Admin Interface and increases the attack surface for Cross Site Request Forgery attacks

Patches The latest OpenMage Versions up from 19.4.6 and 20.0.2 have this Issue solved

References Related to Adobes CVE-2020-9690 ( https://helpx.adobe.com/security/products/magento/apsb20-47.html ) fixed in Magento2 https://github.com/magento/magento2/commit/52d72b8010c9cecb5b8e3d98ec5edc1ddcc65fb4 as part of 2.4.0/2.3.5-p2