Description

Sylius versions before 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9 fail to include firewall identification in JWT tokens issued by separate Admin and Shop API endpoints. Attackers can register a shop customer account using an administrator's email address and obtain a token that the Admin API resolves to that administrator, granting full administrative access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-27T13:16:38.380Z",
  "pubdate": "2026-09-27T13:16:38.380Z",
  "executiveSummary": "This vulnerability is an authentication bypass flaw arising from inadequate JWT validation logic in Sylius.\nThe issue exists because the system fails to verify the specific firewall context (Admin vs. Shop API) during token validation.\nAn attacker can exploit this by registering a customer account on the Shop API using an email address associated with an administrator account.\nBecause the JWT is not bound to a specific firewall, the Admin API mistakenly accepts tokens generated for a Shop user if the identity (email) matches an administrator.\nThis results in total administrative privilege escalation, allowing unauthorized access to the Admin panel and full system control.\nThe vulnerability affects Sylius versions prior to 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9.\nRisk is critical as it requires no elevated privileges to initiate, only the ability to register an account with a target email address.",
  "technicalDetails": "The root cause of this vulnerability is the lack of firewall identification within the JSON Web Token (JWT) claims processed by the Sylius authentication layer.\nIn a secure implementation, an authentication token should be cryptographically bound to the intended application context (firewall).\nSylius employs distinct firewalls for the Admin API and the Shop API; however, the validation mechanism for incoming JWTs in the Admin API fails to verify the 'firewall' context of the token payload.\nThe attack flow begins when an attacker performs a standard user registration on the Shop API using an email address that belongs to an existing administrative user.\nUpon successful registration and subsequent authentication via the Shop API, the system issues a valid JWT based on the provided credentials.\nWhen this token is presented to the Admin API, the authentication provider checks the identity claim against the database.\nBecause the email address matches an administrative user, the backend erroneously assumes the token is legitimate for that user, despite the token having been issued under the Shop API firewall context.\nThe Admin API fails to enforce a check that would determine if the current authentication session originated from the appropriate security firewall.\nConsequently, the Admin API treats the attacker as an authenticated administrator, granting them the same authorization level as the hijacked email identity.\nThis bypass allows full access to administrative API functions without requiring the attacker to know the administrator's actual password.\nThe vulnerable component is the JWT authentication provider configuration and the underlying validation logic that fails to incorporate firewall scope or intent as a mandatory claim for token verification.\nThis vulnerability is highly critical as it circumvents standard access control mechanisms, leading to a complete compromise of the platform's administrative interface."
}