Description

Sylius through 2.3.0 contains an authorization bypass vulnerability that allows unauthenticated attackers to read unmoderated and rejected product reviews because the AcceptedExtension filter is not applied to the item operation. Attackers can enumerate sequential ids on GET /api/v2/shop/product-reviews/{id} to retrieve review titles, ratings, comments, timestamps and author first names, bypassing merchant moderation.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-11T13:17:16.000Z",
  "pubdate": "2026-10-11T13:17:16.000Z",
  "executiveSummary": "Sylius versions through 2.3.0 are susceptible to an authorization bypass vulnerability within the API component, specifically concerning product reviews.\nThis flaw allows unauthenticated, remote attackers to access sensitive, non-public data, including unmoderated and rejected product reviews that should be restricted to administrative view only.\nThe vulnerability stems from an insecure API implementation where the ExpectedExtension filter—a mechanism intended to enforce data visibility policies—is omitted from the item operation.\nImpact includes unauthorized information disclosure, exposing customer sentiment, PII such as author names, and internal moderation statuses, which can be leveraged for competitive intelligence or reputational harm.\nThe vulnerability is trivial to exploit via direct, unauthenticated HTTP GET requests to the /api/v2/shop/product-reviews/{id} endpoint by iterating through predictable sequential record IDs.\nNo elevated privileges or user interaction are required to conduct this enumeration attack, making it highly accessible to external threat actors.",
  "technicalDetails": "The vulnerability originates in the Sylius API layer responsible for handling product review requests, specifically identified at the path /api/v2/shop/product-reviews/{id}.\nThe root cause is a failure to properly apply the 'AcceptedExtension' filter, which acts as an authorization boundary to ensure that only reviews meeting specific moderation criteria are rendered in the API response.\nBecause this filter is omitted from the API resource's item operation definition, the application logic defaults to retrieving the record directly from the database without verifying the 'status' or 'moderation' state of the review.\nThe exploitation flow is straightforward and does not require complex reconnaissance. An attacker can leverage the predictable, sequential nature of the database IDs associated with these review objects.\nBy performing an automated enumeration—scripting successive GET requests targeting incrementing ID values—an attacker can bypass the intended business logic that hides unapproved or rejected content.\nThe JSON response returned by the API during this unauthorized access contains sensitive fields, including the review title, rating, comment text, timestamp of submission, and the author's first name.\nThis represents a failure of the principle of least privilege, as the shop API interface—designed for public consumer interaction—is effectively leaking administrative-level data.\nThe attack is persistent across the network and accessible to any client capable of issuing standard HTTP GET requests. Since the application fails to perform a state check on the requested entity, the system incorrectly assumes that access to the ID implies authorization to view the contents of the entity.\nSuccessful exploitation results in the leakage of potentially disparaging or unverified comments that were intentionally withheld from public view, potentially undermining the integrity of the store's review platform and compromising the privacy of the individuals who submitted the reviews."
}