OpenMage magento-lts before 20.19.0 and 21.0.0-beta1 before 21.0.0-beta3 contains an incorrect authorization vulnerability in the template filter's {{layout}} directive, which renders arbitrary layout handles without enforcing the admin/block whitelist that the {{block}} directive applies. Administrators with rights to edit email, CMS, widget or newsletter content can embed {{layout}} with arbitrary handles to render disallowed blocks and disclose limited information.

OpenMage magento-lts before 20.19.0 and 21.0.0-beta1 before 21.0.0-beta3 contains a cross-site request forgery vulnerability in PayPal cancel and decline return handlers that trust only the checkout session without verifying the request came from PayPal. Attackers can lure a shopper into a cross-site GET to paypal/standard/cancel to cancel their recent uninvoiced order, void pending authorizations, and restore items to the cart.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta pre-releases before 21.0.0-beta3 generate customer email-confirmation keys with md5(uniqid()) and customer and administrator password-reset tokens with the non-cryptographic uniqHash(). Unauthenticated attackers can brute-force the roughly 20-bit confirmation key via the unrate-limited confirmAction endpoint to log in as pending customers, or predict administrator reset tokens after recovering generator state.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains an information disclosure vulnerability in MageRssModelResourceOrder::getAllCommentCollection(), which omits the isvisibleonfront filter for invoice, shipment and credit-memo comments. Authenticated customers can open the /rss/order/status feed for their order to read internal staff comments, such as fraud-review and payment notes.

OpenMage magento-lts before 20.19.0 and 21.0.0-beta1 before 21.0.0-beta3 contains a race condition in shopping cart price rule usage limits, because MageSalesRuleModelValidator checks coupon limits without locking and the usage counters are later incremented non-atomically. Unauthenticated attackers, including guest shoppers, can submit concurrent checkouts to redeem a limited coupon more times than its cap allows.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 accepts the free (No Payment Information Required) payment method on orders with a non-zero total because the zero-total check runs only when payment data is imported. An API user with cart permissions can select free via cartpayment.method while the total is zero, raise it with cartcoupon.remove, and submit cart.order to place an unpaid full-price order.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains an incorrect authorization vulnerability because admin controllers' isAllowed() checks fall back to, or only check, parent ACL resources instead of finer per-action permissions. Authenticated restricted administrators can mass cancel or hold orders, rewrite order shipping addresses, export customer report data, or create REST roles despite their role denying those permissions.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a stored cross-site scripting vulnerability in the Dataflow profile run page, which inserts catalog product import row errors into the page without escaping. Unauthenticated attackers can place markup in the store, type, or attributeset columns of an import file to run script in the session of the administrator who imports it.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains an insufficient session expiration vulnerability because MageApiModelSession::renewBySessId() never checks apiuser.isactive and REST OAuth authorization never checks whether the admin user is active. Attackers holding an existing SOAP/XML-RPC session or OAuth access token retain API access after deactivation or API key rotation, reading and modifying customer, order and catalog data.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a stored cross-site scripting vulnerability in MageCatalogModelProductOptionTypeFile, which accepts guest SVG, XHTML, or XML uploads through product File custom options with an empty allowed-extension list. Unauthenticated attackers can send the file URL under media/customoptions/ to victims, executing script in the store origin and exposing administrator sessions when the admin panel shares that origin.

OpenMage Magento LTS before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a cross-site request forgery vulnerability in the admin and storefront OAuth confirm and confirmSimple actions, which accept GET requests without form-key validation. Attackers holding OAuth consumer credentials can lure a logged-in administrator or customer to a crafted confirm URL that authorizes the attacker's request token, then exchange it at /oauth/token for a persistent REST API access token bound to the victim.

OpenMage Magento-LTS before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains an authorization bypass in the /rss/order/status feed because its URL key is unsigned Base64-encoded JSON of the order, increment, and customer ids. Unauthenticated attackers can forge keys from enumerated sequential ids to read other customers' names, items, prices, totals, and status comments when order-status RSS is enabled.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 serves RSS feeds with a text/html content type and does not escape feed entry data, leading to stored cross-site scripting. An unauthenticated guest can submit a product review with script in the nickname, title or text that executes when an administrator opens the pending-reviews feed, enabling admin account takeover.

OpenMage magento-lts before 20.18.2 and 21.0.0-beta1 before 21.0.0-beta3 contains a reflected cross-site scripting vulnerability in its error pages, which print SCRIPTNAME-derived URLs built by errors/processor.php without escaping. Unauthenticated attackers can craft links that trigger uncaught exceptions on servers deriving SCRIPTNAME from the request path, executing script in the storefront origin within victims' browsers.

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 storefront MSRP/MAP popup and Qty Increments notice templates output product names without proper escaping. Attackers with admin product-edit rights can store a malicious product name that executes script when shoppers view product, category, or wishlist pages.

OpenMage magento-lts before 20.18.2 and 21.x before 21.0.0-beta3 validates OAuth 1.0a oauthcallback URLs with a string-prefix check and falls back to accepting any well-formed URL. Attackers holding a leaked consumer key and secret can supply host-suffix, userinfo, or arbitrary callback URLs to capture an approving administrator's or customer's request token and verifier, then obtain an access token with the victim's API privileges.

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.

OpenMage magento-lts before 20.2.0 contains a stored cross-site scripting vulnerability because the TinyMCE WYSIWYG editor fails to filter scripts in specially crafted HTML tags. Attackers can inject an img element with a malicious onmouseover attribute to execute scripts in the browsers of users viewing the rendered content.

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

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 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.

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 Infinite loop in malicious code filter in certain conditions.

Workarounds

None