CVE-2026-100869: Sylius Shop API Auth Bypass Vulnerability

CVE-2026-100869 Overview

CVE-2026-100869 is a broken access control vulnerability [CWE-863] affecting Sylius, an open-source e-commerce platform built on Symfony. Versions prior to 2.1.16 and 2.2.9 fail to restrict payment request actions exposed through the Shop API endpoint. Any customer holding a valid order token can submit arbitrary payment actions, including refund, cancel, or payout, against completed orders. Payment gateways execute these actions while Sylius continues to mark the order as paid. The result is direct financial loss for merchants running affected Sylius storefronts.

Critical Impact
Attackers with knowledge of an order token can trigger refunds on completed purchases, draining merchant funds while retaining ordered goods.

Affected Products

Sylius versions prior to 2.1.16
Sylius versions prior to 2.2.9
Shop API (ApiBundle) component in Sylius 2.x branches

Discovery Timeline

2026-09-27 - CVE-2026-100869 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100869

Vulnerability Analysis

The flaw resides in the Sylius ApiBundle configuration for payment request handling. The Shop API exposes a payment request operation that accepts an action parameter indicating the operation to perform against the payment gateway. Before the patch, the shop-context endpoint accepted any action value, including sensitive operations reserved for administrative use. A customer authenticated with a valid order token could therefore invoke refund, cancel, or payout on an order they placed.

Payment gateways process these requests normally and move funds back to the customer. Sylius does not update the order status to reflect the refund, so the order remains marked as paid and fulfilled. Merchants ship goods and recognize revenue while the money has already been returned.

Root Cause

The root cause is an authorization gap in the API operation definition. The shop payment request operation shared the same action allow-list as the admin context, instead of enforcing a restricted subset. This is a classic missing-authorization defect [CWE-863] where the application fails to differentiate privilege boundaries between caller contexts.

Attack Vector

Exploitation is network-based and requires only possession of an order token, which the Shop API returns to the customer who placed the order. The attacker sends a crafted payment request to the Shop API endpoint with an action value such as refund. No administrative credentials are required.

php

                ->variableNode('default_image_filter')
                    ->defaultValue('sylius_original')
                ->end()
+               ->arrayNode('shop_payment_request')
+                   ->addDefaultsIfNotSet()
+                   ->children()
+                       ->arrayNode('allowed_actions')
+                           ->info('Payment request actions a shop-context caller is allowed to request. Actions such as "refund", "cancel" or "payout" are intentionally excluded.')
+                           ->scalarPrototype()->end()
+                           ->defaultValue(['capture', 'authorize', 'status', 'notify'])
+                       ->end()
+                   ->end()
+               ->end()

Source: Sylius Commit 5813831. The patch introduces an explicit shop_payment_request.allowed_actions configuration node, defaulting to capture, authorize, status, and notify. Destructive actions such as refund, cancel, and payout are intentionally excluded from the shop context.

Detection Methods for CVE-2026-100869

Indicators of Compromise

Shop API requests to the payment request endpoint containing action values of refund, cancel, or payout.
Payment gateway refund events that have no corresponding admin user action or support ticket.
Mismatch between Sylius order status (paid, fulfilled) and payment gateway transaction state (refunded).
Multiple refund requests originating from the same customer IP or order token in a short interval.

Detection Strategies

Parse Sylius ApiBundle access logs for POST requests to payment request routes and alert when the payload action field is outside the expected capture, authorize, status, notify set.
Reconcile daily payment gateway refund reports against admin-initiated refund events logged in Sylius.
Instrument the payment request controller to emit a security event when a shop-scoped caller supplies a non-allow-listed action.

Monitoring Recommendations

Forward Sylius application and web server logs to a centralized log platform for correlation with payment gateway webhooks.
Set alerting thresholds on refund volume per order, per customer, and per hour.
Monitor for anomalous order token reuse patterns, particularly tokens accessed from IP addresses that differ from the original checkout session.

How to Mitigate CVE-2026-100869

Immediate Actions Required

Upgrade Sylius to version 2.1.16 or 2.2.9 or later, depending on your release branch.
Audit payment gateway transaction history for unauthorized refund, cancel, or payout operations since the vulnerable version was deployed.
Reconcile refunded transactions against Sylius order states and open fraud cases for any mismatches.
Rotate order tokens for in-flight orders if feasible, to invalidate any tokens that may have leaked.

Patch Information

The fix was merged in Sylius Pull Request #19214 and shipped in Sylius Release v2.2.9. Technical details are documented in the GitHub Security Advisory GHSA-2rv4-pjmm-7fxf and the VulnCheck Advisory for Sylius. The patch introduces a configurable sylius_api.shop_payment_request.allowed_actions parameter that enforces an allow-list on shop-context payment requests.

Workarounds

If immediate patching is not possible, place a reverse proxy or Web Application Firewall rule in front of the Shop API that rejects payment request payloads with action values other than capture, authorize, status, or notify.
Temporarily disable the Shop API payment request endpoint if business flows allow server-side payment capture only.
Enforce manual review of all refund operations at the payment gateway level until the upgrade is deployed.

bash

# Example ModSecurity rule to block disallowed shop payment actions
SecRule REQUEST_URI "@beginsWith /api/v2/shop/payment-requests" \
    "id:1009001,phase:2,deny,status:403,log,\
     msg:'Blocked disallowed Sylius shop payment action',\
     chain"
  SecRule REQUEST_BODY "@rx \"action\"\s*:\s*\"(refund|cancel|payout)\"" \
      "t:none,t:lowercase"