Drupal Commerce: an order can become an authorization problem

Security Advisory of October 28, 2026. The Drupal team reports that CVE-2026-118539 affects Commerce Core: some routes and entity fields are not sufficiently protected. It confirms active exploitation and warns of a possible financial impact for the seller. The public mechanism is an access control bypass, not an RCE. This is why the case matters: in a store, altering business data or reaching an internal route can cost money without taking control of the server.

Two different decision points

A route answers the question: “Who can call this operation?” An entity field answers: “Who can read or modify this part of the object?” Protecting the route without controlling the fields it exposes potentially allows a prohibited modification to pass; protecting the fields without restricting a route that orchestrates a sensitive operation creates another opening. So-called decoupled APIs make this separation even more important, because a client can send requests directly, without going through the store screens.

The Drupal bulletin does not name routes, fields, or a specific fraudulent transaction. It would therefore be abusive to assert that this CVE still allows you to set your own price, mark an order as paid or read all customer data. These scenarios illustrate what an audit should look for in a store, not what the advisory establishes for that vulnerability. The documented fact is insufficiently controlled access with financial risk and real exploitation.

How to establish the impact on a given site

An authorized test can build a matrix of roles: visitor, customer who owns an order, other customer and operator. For each route concerned by the order flow, it compares the operations permitted on an entity belonging to the requester and on an entity belonging to another user. It separately checks reading, writing, state transitions and calculated fields. The expected result is not deduced from HTTP code alone: ​​a 200 response may be legitimate for public reading, while a silent change to a payment or shipping field may be critical.

A review of the patch would identify the added controls and write targeted regression tests. Prior to this review, caution is to maintain the description at the level published by the project. Drupal further advises auditing orders for inconsistencies, proof that the response should address already possible business effects, as well as the module version.

Version, proof and continuation

Affected branches are 3.0.0 to 3.3.12 and versions prior to 2.41 of branch 2.x; Drupal asks for 3.3.13 or 8.x-2.41 depending on the line used. The inventory should note the version of Commerce Core actually deployed, including store environments with exposed API. In case of suspicion, application logs, order history, status transitions and payment discrepancies must be reconciled. The absence of server malware does not address fraud carried out by a wrongly authorized application operation.

The case reminds us that authorization is a property of each action and each data field, beyond the displayed page. This is a boundary that penetration tests must check with accounts in different roles and objects owned by other users.

Primary source: Drupal Security Advisory SA-CONTRIB-2026-254.