Drupal Commerce Core flaw exploited; update to 3.3.13 now

Attackers are exploiting a highly critical flaw in Drupal Commerce Core, the shopping-cart module for the Drupal content management system, to place orders they never paid for. Drupal's security team published advisory SA-CONTRIB-2026-254 on October 28, 2026, and says the bug "is being actively exploited in the wild." Every store on the module needs two things this week: the 3.3.13 or 8.x-2.41 update, and an audit of recent orders.

The flaw is tracked as CVE-2026-118539. Drupal scores it 21 out of 25, its "Highly critical" band, with the vector AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. In plain words: no login or special access is needed, data can be read and changed, and an exploit exists.

What the flaw lets an attacker do

The module "doesn't sufficiently protect certain routes and entity fields," the advisory says. That is an access bypass: a visitor can reach pages and data fields that should have been locked down. BleepingComputer reports that an unauthenticated attacker can use it to get around the store's access rules.

Centarro, the company that maintains Drupal Commerce, described the attacks in a post by its CEO Ryan Szrama on October 29. Merchants saw four kinds of abuse:

• Orders placed directly, skipping checkout, so the order exists but was never paid.
• Orders that show as paid in the order management screen with no payment record behind them, mainly on sites that expose the JSON:API web service.
• Product prices lowered before checkout.
• Discounts, fees or other adjustments that no staff member or promotion added.

"We received two reports of attempts by malicious users to place fraudulent orders," Szrama wrote. Some orders carried obviously wrong prices, such as $0.01. Others used normal prices. "As of now we do not believe it was scripted or exploited beyond the initial sites," he added. The Drupal Security Team coordinated the testing, packaging and release of the fix on October 28.

Who is affected and what to install

Drupal credits Dan Puccetti, Marcus Johansson and Robert Snyder with reporting the flaw. Six people, including Szrama, are credited with the fix. BleepingComputer puts the module's install base at more than 42,000 websites, citing the project page on drupal.org.

Branch	Affected versions	Fixed version	Drupal requirement (per Rescana)
Commerce Core 3.x	3.0.0 up to, but not including, 3.3.13	3.3.13	Drupal 10.3 or later, or Drupal 11
Commerce Core 8.x-2.x	Every release before 8.x-2.41	8.x-2.41	Drupal 9.3 or later, or Drupal 10

The fix does not stop at Commerce Core. Centarro says Commerce API, Commerce License, Commerce Shipping and Commerce Stripe also received security releases on October 28 and should be updated at the same time. Rescana notes that Drupal filed five lower-rated Commerce Core advisories alongside this one, SA-CONTRIB-2026-255 through 259. A separate Stripe advisory, SA-CONTRIB-2026-263, is rated critical and could let an attacker mark an order as paid without paying.

Centarro also reminds 8.x-2.x users that support for that branch ends when Drupal 12 ships. "We recommend upgrading to 3.x as soon as possible," the post says.

How long the hole has been open

The bug is old. Centarro says exploits have been "theoretically possible" since Commerce Core 8.x-2.18, released May 26, 2020, on sites that use JSON:API. For every other site, the window opened with 8.x-2.25 on June 30, 2021. Centarro frames these as the earliest possible dates, not confirmed attack dates.

The flaw was not in CISA's Known Exploited Vulnerabilities catalog as of the October 29 edition, Rescana reports. The "actively exploited" label comes from Drupal and Centarro themselves. CISA has flagged five Drupal flaws as exploited over the years, BleepingComputer says, most recently a SQL injection bug, CVE-2026-9082, added in May 2026. Drupal core itself patched a critical Field UI code-execution flaw only two weeks ago.

How to audit your orders

Patching closes the door. It does not undo orders already placed through it. Drupal's advisory says sites "should audit their orders for inconsistencies." Centarro's post gives four database checks, each a query store owners can run:

1. Orders placed outside checkout that still have a balance due.
2. Orders whose recorded paid amount is higher than the completed payments on file.
3. Order items with an overridden unit price. Centarro notes the first check would miss a price lowered to $0.01 and then paid.
4. Adjustments, such as custom fees or discounts, that did not come from a promotion.

A hit is not proof of fraud. Staff-placed orders and "name your own price" products also match, so each flagged order needs a human look. Rescana adds that matching the flagged orders' IP addresses and times against access logs for normal checkout paths helps separate the two.

Centarro's operational advice is blunter: do not ship an order because it was placed or because checkout completed. Confirm the payment first. And if your site does not need JSON:API to accept changes, set it to read-only.

What this means for developers

• Patch today, then audit back to 2020. The fix is a routine composer update to 3.3.13 or 8.x-2.41, plus the four companion modules. The audit is the slow part. If your site has exposed JSON:API since May 2020, the four queries need to run over five years of orders, not last week's.
• Treat "shown as paid" as a claim, not a fact. The second attack type creates orders the admin screen reports as paid with no payment entity behind them. Any fulfillment automation that keys off order state alone was trusting a field the attacker could set. Check that your fulfillment step reads payment records, not order state.
• Headless stores carry more risk. Both of the attack types tied to JSON:API, and the earlier 2020 start date, apply to decoupled sites. If the API only serves product data to a front end, make it read-only now, whatever your Drupal version.
• Watch for the companion advisories. Commerce Stripe's separate critical fix matters for anyone using Stripe as a gateway. Update it in the same deploy as Commerce Core.
• Report anything odd. Centarro says it "would always rather review false positive or duplicate reports than not learn about a potential vulnerability." Two merchant reports found this bug after five years in the code.