Sylius Security Release 1.12.25 / 1.13.17 / 1.14.20 / 2.1.16 / 2.2.9: JWT Audience Confusion Lets a Shop Customer Take Over the Admin API

TL;DR — 90 seconds

Sylius's September 2, 2026 security release fixes four independent flaws. GHSA-f6mx-qxjc-55xf (CVSS 8.8) enables admin takeover: the shop and admin API firewalls issue JWTs with the same signature but no audience claim, so a customer who registers with an administrator's email address can authenticate as that administrator. GHSA-77w3-2367-7xvq (CVSS 8.8) allows theft of admin password-reset tokens via a manipulated Host header. GHSA-vv4h-q2x8-74g4 (CVSS 7.5) allows an order total to be inflated after payment capture has already happened, with Sylius wrongly marking the higher total as fully paid. GHSA-2rv4-pjmm-7fxf (CVSS 6.5) lets customers trigger refunds on their own already-paid orders via the shop API. Fix for all four: update to 1.12.25, 1.13.17, 1.14.20, 2.1.16 or 2.2.9, depending on your line.

What is the problem?

All four flaws involve boundaries between the shop and admin contexts, or between the payment and order logic, that turned out to be drawn too loosely.

In GHSA-f6mx-qxjc-55xf, the admin and shop API firewalls issue JWTs using the same signing configuration, with no audience claim identifying which firewall issued a given token. Both firewalls resolve users by email address. If a customer registers using the email address of an existing administrator, they receive a validly signed shop token that the admin API accepts and resolves to that administrator account.

In GHSA-77w3-2367-7xvq, the password-reset feature derives the base URL for the reset link from the incoming Host header instead of a fixed, trusted origin. An attacker who knows only an administrator's email address can submit a reset request with a manipulated Host header; the reset link that lands in the administrator's inbox then points to the attacker's domain, letting them capture the reset token.

In GHSA-vv4h-q2x8-74g4, Sylius recalculates the order total whenever cart contents change, even after a payment gateway has already successfully captured a smaller amount. The existing payment record then gets overwritten with the new, higher total and stays marked as fully paid, even though the gateway only captured the original, smaller amount.

In GHSA-2rv4-pjmm-7fxf, the shop API's payment-request endpoint does not validate the supplied action parameter against an allowlist. Customers can therefore trigger actions such as refund on their own already-paid orders, with no administrative privileges or CSRF interaction required.

Who is affected?

None of the four flaws had a dedicated CVE ID assigned as of this writing; all four are documented solely through their respective GitHub Security Advisory (GHSA). Operators of Sylius 1.x installations are primarily affected by the first two advisories, since payment-request API functionality was only introduced with the 2.x line.

Impact

GHSA-f6mx-qxjc-55xf has the highest damage potential: complete loss of access control over the admin API, including access to orders, products, customer data and other administrator accounts. The precondition, that an attacker knows an existing administrator's email address and registers as a customer with it, is a low bar in practice, since administrator email addresses are often visible in imprint pages, support contacts, or earlier data breaches.

GHSA-77w3-2367-7xvq requires no access to the administrator's mailbox and, if successful, allows full account takeover. GHSA-vv4h-q2x8-74g4 and GHSA-2rv4-pjmm-7fxf mainly affect financial integrity: merchants can end up shipping goods worth more than the amount actually captured, or customers can grant themselves refunds on orders they already paid for.

Mitigation / immediate actions

Update to the patched version matching your line:

# Composer update per line
composer require sylius/sylius:1.12.25 --with-all-dependencies   # 1.12.x
composer require sylius/sylius:1.13.17 --with-all-dependencies  # 1.13.x
composer require sylius/sylius:1.14.20 --with-all-dependencies  # 1.14.x
composer require sylius/sylius:2.1.16 --with-all-dependencies   # 2.1.x
composer require sylius/sylius:2.2.9 --with-all-dependencies    # 2.2.x

php bin/console doctrine:migrations:migrate --no-interaction
php bin/console cache:clear

Note on GHSA-f6mx-qxjc-55xf: after the update, newly issued tokens carry aud and principal_type claims. Tokens issued before the update lack these claims and are rejected by both API sections after the update. Existing sessions and long-running API integrations holding stored tokens need to re-authenticate after the update.

Also check whether your configuration uses a fixed, trusted hostname for security-relevant links instead of relying on the incoming Host header (Symfony's trusted_hosts configuration).

Detection / verification

Review your access logs for the following indicators:

# Admin API access with unusual token-issuance timing
grep "POST /api/v2/admin" access.log | grep -v "known-admin-ips"

# Password-reset requests with an unexpected Host header
grep "POST /api/v2/admin/password-reset" access.log

# Unusual refund actions on shop payment-request endpoints
grep "payment-requests" access.log | grep -i "refund"

Also check your database for customer accounts whose email address matches an administrator account's email. That is the basic precondition for GHSA-f6mx-qxjc-55xf and should be prevented regardless of patch status.

Operator recommendation

Act today if: you run a Sylius installation below 1.12.25 / 1.13.17 / 1.14.20 / 2.1.16 / 2.2.9, especially with a publicly reachable admin API. Patch immediately and check for email collisions between customer and administrator accounts.

Monitoring is enough if: you have already updated to one of the patched versions and the admin API is reachable only from a trusted network. Reviewing the detection guidance for the period before the update is still worthwhile.

Conclusion

The September 2, 2026 security release bundles four independent but conceptually related problems: boundaries between the shop and admin contexts, and between the payment and order logic, drawn too loosely. If you run Sylius with a publicly reachable admin API and the payment-request API enabled, treat all four advisories as one connected package rather than patching only the most critical one.

Sources

• Sylius: Security release 1.12.25, 1.13.17, 1.14.20, 2.1.16 and 2.2.9
• GHSA-f6mx-qxjc-55xf: JWT audience confusion allows shop customer to authenticate as administrator
• GHSA-77w3-2367-7xvq: Administrator password-reset link is built from the request Host header
• GHSA-vv4h-q2x8-74g4: Order total can be inflated after a Payment Request has started a gateway transaction
• GHSA-2rv4-pjmm-7fxf: Shop API accepts arbitrary PaymentRequest actions