Sylius EUVD-2026-96890

No special conditions - remote unauthenticated exploitation against default configurations of Sylius where the shop REST API (/api/v2/shop) is exposed, which is standard for storefront deployments. The only prerequisite is network reachability of the shop API endpoint. Limiting factors that bound real-world impact: the flaw is read-only and leaks only low-sensitivity data (review titles, ratings, comments, timestamps, author first names), it does not expose full identities, credentials, or order/payment data, and it does not permit any modification; exposure also assumes the product-review resource exists and IDs are predictably sequential for enumeration.

This is a genuine but moderate-priority issue, not a top-tier emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N, base 6.9) is internally consistent with the description: remote, unauthenticated, low-complexity access to the shop REST API, with only limited confidentiality impact and zero integrity/availability impact. My independent CVSS 3.1 assessment lands at ~5.3 (C:L only), reinforcing that this is an information-disclosure flaw, not a code-execution or data-tampering flaw. Exploitation is trivial - sequential ID enumeration on a public endpoint - and a detailed public technical write-up (hackmd) plus the exact vulnerable source file (AcceptedExtension.php) are referenced, which materially lowers the barrier to exploitation even though no packaged weaponized exploit is cited. No EPSS score and no KEV status were provided in the input, so probabilistic exploitation likelihood and confirmed in-the-wild use cannot be asserted; absence here is unknown, not zero. Weighing the signals: trivial exploitability and public method detail push risk up, while the strictly read-only, low-sensitivity data exposure (review text and author first names) and lack of any confirmed active exploitation keep real-world severity bounded. Treat as a prompt-but-scheduled patch, prioritized higher for merchants whose shop API is internet-facing and who rely on review moderation for brand/compliance reasons.

An unauthenticated attacker scripts iterative GET requests to /api/v2/shop/product-reviews/{id}, walking sequential numeric IDs. Because the AcceptedExtension moderation filter is not applied to the item operation, the API returns reviews that merchants intentionally hid or rejected, letting the attacker harvest review titles, ratings, comments, timestamps and author first names. A public hackmd write-up documents the exact enumeration technique, so no special tooling is needed.