Drupal Commerce CVE-2026-118539: Exploited Auth Bypass, Audit Orders

Most exploited web flaws leave their evidence in access logs or a dropped web shell. The Drupal Commerce Core bug now under attack, CVE-2026-118539, is likelier to leave it in the order table. Drupal describes it as an access bypass that "may financially impact the vendor," and its only advice beyond updating is to audit orders for inconsistencies. That second line is the part most coverage skipped, and it is where a store owner finds out whether this cost them money.

Drupal published advisory SA-CONTRIB-2026-254 and the fixed releases on October 28, rated it Highly critical (21 out of 25), and stated the flaw is being actively exploited in the wild. Canada's Cyber Centre repeated the exploitation warning on October 30. As of November 1 it is not in CISA's Known Exploited Vulnerabilities catalog.

Which Commerce Core versions are affected by CVE-2026-118539?

Every Commerce Core release before 8.x-2.41 on the 2.x line, and every 3.x release before 3.3.13, is affected. The fixes are 8.x-2.41 and 3.3.13. No login is needed to exploit it, and Drupal's risk vector marks all module configurations as exploitable, so a default store install is in scope.

Some early reports listed the affected range as running "through 2.41" and "through 3.3.13." That reads as if the fixed versions were vulnerable too. They are not: Drupal's advisory names 2.41 and 3.3.13 as the releases that close the hole. If your site reports either of those, the exploited bug is fixed.

Commerce Core is the module that turns a Drupal site into a shop: cart, checkout and the APIs behind headless storefronts. BleepingComputer puts its footprint at more than 42,000 sites. The 3.x branch runs on Drupal 10.3 and 11.

Why updating does not close the incident

Drupal has said only that the module failed to protect "certain routes and entity fields." It has not named which ones, what an attacker changes, or when exploitation began. None of the three people credited with reporting it (Puccetti, Johansson and Snyder) has put out a write-up.

Read together, those facts point somewhere specific. An authorization gap on commerce entities, with a financial impact on the merchant, is a business-logic bug. It does not need to execute code, so the usual signals of a compromised PHP site (new files, odd processes, outbound connections) may never fire. The trace, if there is one, sits in order records that look like ordinary sales.

That changes the order of work. Updating stops new abuse within minutes. It does nothing about an order that was already altered, under-paid or pushed through checkout before the update landed. Those stay in your books, and in your fulfilment queue, until someone looks.

It is at least the second exploited Drupal flaw this year. In May, according to BleepingComputer, it was an SQL injection in core's database layer (CVE-2026-9082), which is now listed in CISA's Known Exploited Vulnerabilities catalog. We saw the same shape on the Magento side with StyleSmuggler: on a shop, the patch is step one and the hunt through store data is step two.

How to reconcile orders after CVE-2026-118539

Because Drupal has not said which fields were exposed, there is no confirmed signature to grep for. What you can check is whether the money adds up. The queries below run against the default Commerce 2.x and 3.x database tables. Adjust the table prefix if your install uses one, and pick a start date well before October 28, since nobody has said when attacks began.

SELECT o.order_id, o.order_number, o.state,
       o.total_price__number, o.total_paid__number,
       FROM_UNIXTIME(o.placed) AS placed_at
FROM commerce_order o
WHERE o.placed >= UNIX_TIMESTAMP('2026-09-01')
  AND o.state NOT IN ('draft', 'canceled')
  AND COALESCE(o.total_paid__number, 0) < o.total_price__number;
SELECT oi.order_id, oi.title, oi.quantity,
       oi.unit_price__number, oi.total_price__number,
       oi.overridden_unit_price
FROM commerce_order_item oi
JOIN commerce_order o ON o.order_id = oi.order_id
WHERE o.placed >= UNIX_TIMESTAMP('2026-09-01')
  AND o.state NOT IN ('draft', 'canceled')
  AND (oi.unit_price__number <= 0 OR oi.overridden_unit_price = 1);

The first query lists placed orders that were never paid in full. The second lists line items sold at zero or below, or with a manually overridden price. Both will return some legitimate rows: manual payment methods, free promotions and staff price edits all look like this. The point is a short list a human can check against the payment gateway's own records, which the attacker could not edit through Drupal.

Two more checks are worth the time. Compare the order count and revenue per day from late October with the weeks before; a quiet spike in small or zero-value orders is the pattern to explain. And hold any unshipped order that fails reconciliation, because fulfilment is where the loss becomes real.

The same release fixes five more Commerce Core advisories

Version 3.3.13 is not a one-bug release. Drupal shipped it with six advisories, and the five lower-rated ones still matter for some stores:

Two of these tie back to the exploited bug. SA-CONTRIB-2026-257 lets a vendor on a multi-store marketplace make their store the site default, so orders meant for others land with them. That is another order-integrity problem, and marketplace operators should include store ownership in their audit.

The other is SA-CONTRIB-2026-258, a cross-site request forgery (CSRF) in the Commerce admin inbox. One administrator tricked into opening a page can dismiss inbox notices for every administrator, security-update notices included, because the inbox is shared. On a store with an exploited flaw in circulation, a hidden update notice is the last thing you want.

Update Commerce Core first, then reconcile orders

1. Check the installed version with composer show drupal/commerce. Anything below 3.3.13 on 3.x, or below 8.x-2.41 on 2.x, is exposed.
2. Update with Composer (composer require 'drupal/commerce:^3.3' on the 3.x line), then run database updates with drush updatedb and clear caches.
3. Run the reconciliation above for the weeks before the update, and match every flagged order against the payment gateway's records.
4. Hold unshipped orders that do not reconcile until you have checked them.

If you cannot update today

Drupal published no workaround and no configuration switch for this flaw. The only stopgap that removes the exposure is taking checkout offline, for example with Drupal's maintenance mode, until the update is in. For a store that hurts, but a day of lost sales is easier to account for than a week of orders you cannot trust.

If you run more than one Drupal store, the harder question is inventory: knowing which sites carry Commerce and which version each one runs before the next advisory lands. That is the job of continuous vulnerability detection, and when the order audit does turn something up, an incident response plan decides what happens next. For the PHP layer underneath these stores, see our note on PHP2Shell, exploited the same week.