A Sylius Customer Login Could Open the Admin API
Sylius disclosed these security problems on 2 September 2026. The three corresponding NVD records arrived on 27 September; that later indexing was not a new disclosure. Operators need to examine access to administration and the money actually captured for orders marked paid. An authentication update does not reconcile earlier transactions.
Customer tokens could unlock administration
CVE-2026-100871 let validly signed tokens cross contexts without issuer-context claims. Separate tables let customers register the known administrator’s email, use their own password and submit the token as administrator. Exposure required the API enabled, registration open and that administrator eligible. Reverse confusion worked.
Affected ranges start at 1.11.0. Fixes validate context and identity class, invalidating old tokens. Renamed or added firewalls need listener mapping; tokens otherwise fail.
The genuine reset email pointed to the attacker’s host
CVE-2026-100870 begins at 1.12.0 and affects administrator recovery through the form and interface. Without trusted-host restrictions, an unauthenticated requester knowing the address could forge the Host header, or proxy-forwarded naming when that intermediary is trusted. The real service emailed a valid token to the administrator, but the link led to the intruder’s domain. Only after the recipient followed it could the requester capture the token, reuse it at the real shop and choose a password. Customer resets were unaffected.
The repair selects the configured channel host, falling back to a bare token if none is suitable. Update any override of adminPasswordReset.html.twig too; an unchanged local template can preserve the problem after upgrading. Host restrictions remain useful afterwards.
The payment gateway captured less than the order showed
In the affected 2.x flow, CVE-2026-100872 let a guest start a small purchase, allow capture and enlarge the order before asynchronous confirmation. Recalculation changed the recorded amount or currency, while completion checked status rather than matching captured funds to the new total. Making the order free could also delete a payment already in progress.
The correction protects payments submitted for capture or authorisation and creates a separate payment for any difference. An outstanding balance then remains unpaid. Timing matters: the release overview’s offline bank-transfer example leaves the cart synchronously and cannot reproduce this sequence. Verify the actual integration rather than assuming all gateways behave alike.
First corrected releases
| Branch and first fixed build | Covered paths |
|---|---|
| 1.12.25 | Token and reset |
| 1.13.17 | Token and reset |
| 1.14.20 | Token and reset |
| 2.1.16 | All three |
| 2.2.9 | All three |
These are repair floors, not latest releases. Older branches, including 2.0, lack maintenance fixes: migrate or use the advisory’s interim instructions. The payment issue does not affect 1.x.
A fourth notice covers customer-requested payment actions. It requires an enabled shop interface and a gateway offering a refund-class operation. The standard installation has no such gateway and is not exploitable by default. That is a separate issue from the three examined here.
Check the upgrade and earlier activity
- Install the appropriate corrected release; a web-application firewall does not replace the authentication repairs.
- Restrict accepted hostnames at both the application and reverse proxy.
- Arrange fresh authentication for customer and administrator integrations, including customised firewalls.
- Investigate customer accounts sharing administrators’ addresses, especially those created shortly before management activity.
- Review recovery requests’ host values and the destination domains in administrator reset traffic.
- Compare actual gateway captures with final order totals and investigate mismatches, rather than relying on completed status.
The reviewed notices do not report attacks in the wild; their silence does not prove absence. Our separate Adobe Commerce investigation shows why patching still needs an investigation of earlier activity. Its confirmed exploitation is not evidence of exploitation against this platform.
Primary sources and chronology
- Release overview: 2 September 2026; no publication time supplied.
- Token advisory: 13:57:44 UTC, same date.
- Administrator recovery advisory: 2 September 2026, 13:57:50 UTC.
- Order-total advisory: 2 September 2026, 13:57:39 UTC.
- Separate payment-action notice: fourth-issue context.
- The three NVD entries were published on 27 September 2026 at 13:16:38 UTC. Local summer time was two hours ahead of UTC for all dates above.
