How Can a Drupal Commerce Store Tell a Paid Order From a Faked One?

The reports came from merchants, not from a laboratory. Two store owners watching live Drupal Commerce sites saw orders that did not add up, and they told the people who maintain the software. Centarro, which maintains Commerce Core, worked through the problem in private with Drupal’s security team, and the fix shipped on October 28 as Commerce Core 3.3.13. The flaw it closed, CVE-2026-118539, is an access bypass in the module that runs carts and checkout on more than 42,000 sites by Drupal’s usage statistics. Drupal rates it 21 out of 25 on its own risk scale. The rating treats it as exploitable without logging in, on any configuration of the module.

Some of the orders carried prices that were plainly wrong. One example the maintainers gave was $0.01. Others carried ordinary prices, which is why a scan for cheap orders alone would miss them. The common thread was not the amount. It was the record behind the amount: an order that existed, and in some cases looked paid, without the payment that should have produced it. Drupal’s advisory describes the flaw as missing protection on certain routes and entity fields, says it is being actively exploited in the wild, and warns that it may financially affect the vendor. Its instruction to store owners is short: update, and audit orders for inconsistencies.

Centarro’s post, published in consultation with the security team, names merchants as the people who reported the flaw. “Those who reported the issue were merchants who observed suspicious activity on live sites, not merely security researchers evaluating the platform for vulnerabilities.” The post records two reports of attempts to place fraudulent orders. It also records the limit of what the maintainers could establish. “As of now we do not believe it was scripted or exploited beyond the initial sites,” the post says. Drupal has not named an attacker, counted the affected stores, or put a figure on losses.

An order that was placed but never paid, with no pending or authorized payment attached, is the first thing to look for on a store that does not legitimately sell free items. Centarro arranges the checks from the crudest abuse to the most careful. The second check catches the cleverer version: an order that reads as paid in the order system while no payment record exists behind it, which points to a payment being simulated rather than made. That version matters most on sites that let outside software update Commerce data through Drupal’s JSON:API module, the interface decoupled storefronts use to talk to the back end.

A product price that no promotion or price rule on the site can explain suggests someone changed the price before checkout finished or placed the order by another route. Discounts, fees or other adjustments that nobody on staff added, and that no promotion produces, point the same way. One mark is the “Override the unit price” box ticked on an order item where staff would not normally tick it. The other is unknown adjustments showing in the order total summary. None of these marks proves fraud on its own. Staff overrides and donation products leave the same traces, and Centarro says it is still a matter of judgment whether a result represents an actual exploit.

Checkout sets an order’s checkout step to complete when it places the order. The exploit places the order directly and leaves that step unchanged, so an order with a balance due and a checkout step that is not complete stands out in the database. Centarro published four database queries that run the four checks. It says the best confirmation is still the dullest one: match an order’s IP address and time against the access logs and confirm it arrived through the normal path, beginning with /checkout/. An order that cannot be matched to that path needs reconciling before it is fulfilled.

The window for that check is longer than the week of the disclosure. Centarro writes that exploits were theoretically possible since Commerce Core 8.x-2.18, released on May 26, 2020, on sites using the JSON:API module, and since Commerce Core 8.x-2.25, released on June 30, 2021, for all other sites. Full-stack stores and headless stores are both affected, with attack routes that differ by architecture. Centarro frames both dates as theoretical possibility, not as evidence that anyone used the flaw in 2020. A review limited to the last few days leaves most of that window unexamined.

Commerce Core is a module, and its version is separate from the version of Drupal core running the site. Updating Drupal core alone therefore leaves the flaw in place. Stores on the 3.x line need Commerce Core 3.3.13; stores on the older line need 8.x-2.41, whose support ends when Drupal 12 is released. Centarro also packaged security releases the same day for Commerce API, Commerce License, Commerce Shipping and Commerce Stripe, and says they should be updated at the same time. Where a site does not need to support update operations through JSON:API, the maintainers recommend switching that interface back to read-only, and updating anyway.

The release that carries the fix carries five more. Commerce Core 3.3.13 also closes a moderately critical disclosure of unpublished product variations through JSON:API. It closes a less critical flaw letting a user who manages only their own promotions delete or change another promotion’s coupons. And it closes a moderately critical flaw letting a user who can create or edit their own store mark it as the site’s default store and receive orders meant for others.

A moderately critical cross-site request forgery flaw, CVE-2026-118543, sits in the Commerce dashboard inbox that carries project announcements. Its routes did not check for a forgery token. Tricking one commerce administrator into visiting a crafted page could dismiss notifications for every administrator at once, including the notice that a security update is available. The warning about the patch itself was among the notices that could be dismissed. The sixth fix closes a second information disclosure through entity queries on unpublished variations.

Thirty-nine security advisories were published on October 28. It was the busiest day in the project’s records since 2018. The five months from June through October produced 256 advisories against 250 across the previous 30 months combined. The Drupal Association says the surge comes from a change in the economics of finding flaws, with automated and AI-assisted analysis making latent bugs in mature code cheap to identify, not from a change in Drupal’s attack surface. A highly critical SQL injection flaw in Drupal core drew exploitation attempts in May, a listing in the United States Cybersecurity and Infrastructure Security Agency’s known-exploited catalogue, and a three-day patch order for federal agencies. Two critical remote code execution flaws fixed on October 14 drew a warning that exploits might appear within hours or days. So far, no public reports of exploitation have followed.

Commerce Core 3.3.13 runs on Drupal 10.3 and 11. Centarro’s post states the standing rule for every store: checkout completion stages an order for fulfillment, and the details of an order, including full payment, are confirmed before any goods or services are delivered.