CVE-2026-100871 in Sylius
Summary
by MITRE • 09/27/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/27/2026
The vulnerability identified in Sylius versions prior to 1.12.25, 1.13.17, 1.14.20, 2.1.16, and 2.2.9 represents a critical authentication bypass resulting from improper token generation logic within the JSON Web Token implementation. The core technical flaw lies in the failure to include firewall identification or context-specific identifiers within the JWT claims when tokens are issued by distinct API endpoints, specifically separating Admin and Shop APIs. In secure architectural designs utilizing multiple firewalls for different user roles, each authentication endpoint must embed unique contextual data into the token payload that explicitly binds the credential set to its originating security domain. By omitting this firewall identifier, Sylius creates a scenario where tokens generated through one entry point are structurally indistinguishable from those intended for another when processed by the central authorization logic. This design oversight allows an attacker to exploit the shared validation mechanism across different API gateways without proper scope restriction enforcement at the token issuance stage.
The operational impact of this flaw is severe, as it enables a complete privilege escalation attack vector against administrative functions. An adversary can register a new customer account using an email address associated with an existing administrator within the Shop API endpoint. Upon successful registration and authentication through this public-facing shop interface, the system issues a JWT token that lacks the necessary firewall context to restrict its usage scope. When this token is subsequently presented to the Admin API, the authorization layer fails to detect the mismatch between the token's origin (Shop) and the requested access level (Admin). Consequently, the server resolves the user identity based solely on the email address or unique identifier contained in the token, granting the attacker full administrative privileges equivalent to a legitimate system administrator. This effectively bypasses all role-based access controls designed to isolate customer interactions from backend management operations.
From a classification perspective, this vulnerability aligns with CWE-287, which denotes Improper Authentication, specifically falling under scenarios where authentication credentials are misused or incorrectly validated due to missing contextual constraints. It also maps closely to ATT&CK technique T1078, Valid Accounts, as the attacker leverages legitimate account structures and token formats to gain unauthorized access. Furthermore, the failure to enforce distinct security contexts for different API endpoints relates to CWE-269, Improper Privilege Management, because the system fails to maintain appropriate separation of duties between customer-facing services and administrative interfaces. The lack of firewall identification in JWT claims violates fundamental principles of secure token design where tokens must be scoped strictly to their intended audience and purpose.
Mitigation strategies require immediate updates to all affected Sylius installations by upgrading to version 1.12.25, 1.13.17, 1.14.20, 2.1.16, or 2.2.9, which contain the necessary patches to enforce firewall identification within issued JWT tokens. In addition to patching, organizations should implement defense-in-depth measures such as strict audience validation in token consumers and ensuring that API endpoints explicitly check for context-specific claims before granting access. Security teams should also audit their authentication flows to ensure that no other services rely on ambiguous token structures that could be exploited similarly. Regular penetration testing focusing on cross-service privilege escalation paths is recommended to verify the effectiveness of these controls and identify any residual risks in custom integrations or third-party modules that may not adhere to standard Sylius security patterns.