Drupal advisory SA-CONTRIB-2026-254, published October 28, 2026; coverage October 30, 2026
Drupal Commerce Stores Are Being Exploited Through an Access Bypass That Reaches the Order Itself
Drupal warned on October 28 that a highly critical missing authorization flaw in its Commerce Core module is being actively exploited in the wild. The flaw, CVE-2026-118539, classified as CWE-862 and rated 21 out of 25 on Drupal own risk scale, comes from the module not sufficiently protecting certain routes and entity fields, leading to an access bypass that Drupal says may financially impact the vendor. Commerce Core, which provides the shopping cart, checkout form, and API-based selling used by more than 42,000 sites, is affected in versions from 0.0.0 up to 2.41 on the earlier line and from 3.0.0 up to but not including 3.3.13 on the 3.x line. The fixes are Commerce Core 8.x-2.41 and 3.3.13, released with the advisory. Drupal credited Dan Puccetti, Marcus Johansson, and Robert Snyder with reporting the flaw, acknowledged active exploitation, and gave no specifics about the campaign, the stores targeted, or the technique beyond the route and field description. Analyst commentary in coverage of the advisory points to the transaction as the target, order totals, pricing, coupons, and payment state, rather than code execution or site takeover, and notes that the resulting requests can look like ordinary storefront traffic and need no credentials and no malware. Drupal one instruction beyond upgrading is to audit orders for inconsistencies. As of the October 30 coverage, the flaw had not been added to the CISA KEV catalog, which makes the vendor advisory, not the federal catalog, the trigger for action.
Executives
This flaw attacks revenue directly rather than data: the asset at risk is the integrity of orders already placed, which means the response has two halves, patch the module and reconcile the order book. A store that patches without auditing cannot say whether it already shipped goods against manipulated totals or payment states. For any business selling through Drupal Commerce, the audit instruction in the advisory is the part to confirm was actually done.
CIO / CISO
Upgrade to 8.x-2.41 or 3.3.13 immediately, then commission the historical review Drupal directs: orders with totals, discounts, or payment states that do not reconcile, going back as far as your logs and order records allow, since the advisory does not say when exploitation began. Because exploitation needs no login and resembles normal store traffic, detection rests on order and payment reconciliation rather than intrusion alerts, so involve whoever owns payment settlement, not only the web team. For stores handling card payments, fold the incident record into your PCI DSS evidence for incident handling and change control.
Engineers
Apply the fixed release for your branch and verify the running module version afterward, since Commerce Core can be present inside a larger Drupal installation where it is easy to overlook. Then run the order audit as a data query, not a log skim: flag orders whose paid amount differs from the calculated total, whose coupon or adjustment values fall outside configured rules, or whose payment state advanced without a matching gateway record, and have a human review each flag before treating it as fraud, because legitimate staff actions can produce similar patterns.
Everyone (non-IT)
If you shop at a store built on Drupal, there is nothing for you to do, and no sign in this advisory that customer accounts or card numbers were the target. The risk sits with the store order records, which is why a careful store may contact customers about a specific order if its audit finds a problem with that order.