Package Instance

Cross-site Scripting
XSS injection in the Grid component.

Sylius has a security vulnerability via adjustments API endpoint
A security vulnerability was discovered in the `/api/v2/shop/adjustments/{id}` endpoint, which retrieves order adjustments based on incremental integer IDs. The vulnerability allows an attacker to enumerate valid adjustment IDs and retrieve order tokens. Using these tokens, an attacker can access guest customer order details - sensitive guest customer information.

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

Generation of Error Message Containing Sensitive Information
In affected versions of Sylius, exception messages from internal exceptions (like database exception) are wrapped by \Symfony\Component\Security\Core\Exception\AuthenticationServiceException and propagated through the system to UI. Therefore, some internal system information may leak and be visible to the customer. A validation message with the exception details will be presented to the user when one will try to log into the shop. This has been patched in versions 1.3.14, 1.4.10, 1.5.7, and 1.6.3.

Cross-site Scripting
In Sylius, the user may register in a shop by email `mail@example.com`, verify it, change it to the mail `another@domain.com` and stay verified and enabled. This may lead to having accounts addressed to totally different emails, that were verified. Note, that this way one is not able to take over any existing account (guest or normal one). The issue has been patched in Sylius As a workaround, you may resolve this issue on your own by creating a custom event listener, which will listen to the `sylius.customer.pre_update` event. You can determine that email has been changed if customer email and user username are different. They are synchronized later on. Pay attention, to email changing behavior for administrators. You may need to skip this logic for them. In order to achieve this, you should either check master request path info, if it does not contain `/admin` prefix or adjust event triggered during customer update in the shop. You can find more information on how to customize the event here.

Exposure of Sensitive Information to an Unauthorized Actor
Sylius is an open source eCommerce platform. Prior to versions 1.9.10, 1.10.11, and 1.11.2, any other user can view the data if browser tab remains unclosed after log out. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. A workaround is available. The application must strictly redirect to login page even browser back button is pressed. Another possibility is to set more strict cache policies for restricted content.

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 has potential Cross Site Scripting vulnerability via the "Province" field in the Checkout and Address Book
There is a possibility to save XSS code in province field in the Checkout and Address Book and then execute it on these pages. The problem occurs when you open the address step page in the checkout or edit the address in the address book. This only affects the base UI Shop provided by Sylius.

Cross site scripting in sylius/sylius
sylius/sylius versions prior to 1.9.10, 1.10.11, and 1.11.2 are vulnerable to stored cross-site scripting (XSS) through SVG files. This vulnerability allows attackers to inject malicious scripts that can be executed in the context of the user's browser.

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

Withdrawn Advisory: Sylius allows unrestricted brute-force attacks on user accounts
## Withdrawn Advisory
This advisory has been withdrawn because it is not a vulnerability in the Sylius framework. This link is maintained to preserve external references.

## Original Description
A rate limiting issue in Sylius v2.0.2 allows a remote attacker to perform unrestricted brute-force attacks on user accounts, significantly increasing the risk of account compromise and denial of service for legitimate users.

Improper Restriction of Rendered UI Layers or Frames
Sylius is an open source eCommerce platform. Prior to versions 1.9.10, 1.10.11, and 1.11.2, it is possible for a page controlled by an attacker to load the website within an iframe. This will enable a clickjacking attack, in which the attacker's page overlays the target application's interface with a different interface provided by the attacker. The issue is fixed in versions 1.9.10, 1.10.11, and 1.11.2. A workaround is available. Every response from app should have an X-Frame-Options header set to: ``sameorigin``. To achieve that, add a new `subscriber` in the app.