Package Instance

Sylius has a XSS vulnerability in checkout login form
A cross-site scripting (XSS) vulnerability exists in the shop checkout login form handled by the ApiLoginController Stimulus controller.

When a login attempt fails, AuthenticationFailureHandler returns a JSON response whose message field is rendered into the DOM using innerHTML, allowing any HTML or JavaScript in that value to be parsed and executed by the browser.

The message value originates from `AuthenticationException::getMessageKey()` passed through Symfony's translator (security domain, using the request locale). In the default Sylius installation, this returns a hardcoded translation key (e.g. "Invalid credentials."), which is not directly user-controlled. However, using innerHTML with server-derived data violates defense-in-depth principles, and the risk escalates significantly under realistic scenarios:
- Customized authentication handlers — if a project overrides AuthenticationFailureHandler to include user-supplied data in the message (e.g. "No account found for <username>"), an attacker can inject arbitrary JavaScript directly via the login
form without any privileged access.
- Translation injection — if translation files are sourced from an untrusted database or CMS and contain HTML, the message could carry a malicious payload.
- Man-in-the-Middle — if the response is intercepted (e.g. on HTTP or via a compromised proxy), an attacker can inject arbitrary HTML/JS into the message field.
- Server-side injection — if any middleware, reverse proxy, or error handler modifies the JSON response body, malicious content could be injected into the message field.

Exploitation could lead to session hijacking, credential theft, cart/order manipulation, or phishing within the trusted shop domain.

The vulnerability affects all Sylius installations that use the default shop checkout login form with the bundled ApiLoginController.js.

Sylius Vulnerable to Authenticated Stored XSS
An authenticated stored cross-site scripting (XSS) vulnerability exists in multiple places across the shop frontend and admin panel due to unsanitized entity names being rendered as raw HTML.

**Shop breadcrumbs** (`shared/breadcrumbs.html.twig`): The `breadcrumbs` macro uses the Twig `|raw` filter on label values. Since taxon names, product names, and ancestor names flow directly into these labels, a malicious taxon name like `<img src=x onerror=alert('XSS')>` is rendered and executed as JavaScript on the storefront.

**Admin product taxon picker** (`ProductTaxonTreeController.js`): The `rowRenderer` method interpolates `${name}` directly into a template literal building HTML, allowing script injection through taxon names in the admin panel.

**Admin autocomplete fields** (Tom Select): Dropdown items and options render entity names as raw HTML without escaping, allowing XSS through any autocomplete field displaying entity names.

An **authenticated administrator** can inject arbitrary HTML or JavaScript via entity names (e.g. taxon name) that is persistently rendered for all users.

Sylius has an Open Redirect via Referer Header
`CurrencySwitchController::switchAction()`, `ImpersonateUserController::impersonateAction()` and `StorageBasedLocaleSwitcher::handle()` use the HTTP Referer header directly when redirecting.

The attack requires the victim to click a legitimate application link placed on an attacker-controlled page. The browser automatically sends the attacker's site as the Referer, and the application redirects back to it. This can be used for phishing or credential theft, as the redirect originates from a trusted domain.

The severity varies by endpoint; public endpoints require no authentication and are trivially exploitable, while admin-only endpoints require an authenticated session but remain vulnerable if an admin follows a link from an external source such as email or chat.

Affected classes:
- `CurrencySwitchController::switchAction()` - public
- `StorageBasedLocaleSwitcher::handle()` - public, used in locale switching without having locale in the `url`
- `ImpersonateUserController::impersonateAction()` - admin-only

Sylius affected by IDOR in Cart and Checkout LiveComponents
Create `src/Twig/Components/Cart/SummaryComponent.php`:

```php
<?php

declare(strict_types=1);

namespace App\Twig\Components\Cart;

use Sylius\Bundle\ShopBundle\Twig\Component\Cart\FormComponent;
use Sylius\Bundle\UiBundle\Twig\Component\ResourceLivePropTrait;
use Sylius\Bundle\UiBundle\Twig\Component\TemplatePropTrait;
use Sylius\Component\Core\Model\OrderInterface;
use Sylius\Component\Core\Repository\OrderRepositoryInterface;
use Sylius\Resource\Model\ResourceInterface;
use Sylius\TwigHooks\LiveComponent\HookableLiveComponentTrait;
use Symfony\UX\LiveComponent\Attribute\AsLiveComponent;
use Symfony\UX\LiveComponent\Attribute\LiveArg;
use Symfony\UX\LiveComponent\Attribute\LiveListener;
use Symfony\UX\LiveComponent\Attribute\LiveProp;
use Symfony\UX\LiveComponent\DefaultActionTrait;

Sylius has a Promotion Usage Limit Bypass via Race Condition
A Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects three independent limits:

1. **Promotion usage limit** - the global `used` counter on `Promotion` entities
2. **Coupon usage limit** - the global `used` counter on `PromotionCoupon` entities
3. **Coupon per-customer usage limit** - the per-customer redemption count on `PromotionCoupon` entities

In all three cases, the eligibility check reads the `used` counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in `OrderPromotionsUsageModifier` happens later during order completion — with no database-level locking or atomic operations between the two phases.

Because Doctrine flushes an absolute value (`SET used = 1`) rather than an atomic increment (`SET used = used + 1`), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously.

An attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous `PATCH /api/v2/shop/orders/{token}/complete` requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability.

This may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons.

Sylius is Missing Authorization in API v2 Add Item Endpoint
The `POST /api/v2/shop/orders/{tokenValue}/items` endpoint does not verify cart ownership. An unauthenticated attacker can add items to other registered customers' carts by knowing the cart `tokenValue`.

```
POST /api/v2/shop/orders/{tokenValue}/items
```

Other mutation endpoints (PUT, PATCH, DELETE) are **not affected**. API Platform loads the Order entity through the state provider for these operations, which triggers `VisitorBasedExtension` and returns 404 for unauthorized users.

An attacker who obtains a cart `tokenValue` can add arbitrary items to another customer's cart. The endpoint returns the full cart representation in the response (HTTP 201), potentially leaking:

- Customer email address
- Cart contents (products, quantities, prices)
- Address data (billing and shipping if set)
- Payment and shipment IDs
- Order totals and tax breakdown
- Checkout state

Sylius has a DQL Injection via API Order Filters
Sylius API filters `ProductPriceOrderFilter` and `TranslationOrderNameAndLocaleFilter` pass user-supplied order direction values directly to Doctrine's `orderBy()` without validation. An attacker can inject arbitrary DQL:

```
GET /api/v2/shop/products?order[price]=ASC,%20variant.code%20DESC
```