CVE-2026-40098

Cross-user wishlist item import via shared wishlist code, leading to private option disclosure and file-disclosure variant

The shared wishlist add-to-cart endpoint authorizes access with a public sharing_code, but loads the acted-on wishlist item by a separate global wishlist_item_id 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:

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

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

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

• quote_path
• order_path
• secret_key

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/quote_item_option ID
• the preserved secret_key

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 secret_key
• reads the file from order_path or quote_path

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:
  • wishlist_id = 1
  • customer_id = 2
  • sharing_code = 6376bb8c37a09c2de3664bd8cdc16412
• victim wishlist B:
  • wishlist_id = 2
  • customer_id = 3
• victim item:
  • wishlist_item_id = 1
  • wishlist_id = 2
  • product_id = 2
• victim private text option marker:
  • VICTIM-MARKER-49040822

Reproduction

Send:

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

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:

option_1 = 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:

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

The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.

CVE-2026-40098 has a CVSS score of 5.4 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (20.17.0); upgrading removes the vulnerable code path.

Kodem intelligence

In SharedController::cartAction(), reject any request where the loaded item does not belong to the wishlist loaded from the share code:

$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 + secret_key

1. What is CVE-2026-40098? CVE-2026-40098 is a medium-severity missing authorization vulnerability in openmage/magento-lts (composer), affecting versions < 20.17.0. It is fixed in 20.17.0. The application does not perform an authorization check before performing a sensitive operation.
2. How severe is CVE-2026-40098? CVE-2026-40098 has a CVSS score of 5.4 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of openmage/magento-lts are affected by CVE-2026-40098? openmage/magento-lts (composer) versions < 20.17.0 is affected.
4. Is there a fix for CVE-2026-40098? Yes. CVE-2026-40098 is fixed in 20.17.0. Upgrade to this version or later.
5. Is CVE-2026-40098 exploitable, and should I be worried? Whether CVE-2026-40098 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-40098 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-40098? Upgrade openmage/magento-lts to 20.17.0 or later.