Drupal Commerce CVE-2026-118539 Exploited: Audit Your Orders

Drupal Commerce CVE-2026-118539 is an access bypass in Commerce Core that Drupal says is being actively exploited. The fix shipped on 28 October 2026 in Commerce Core 3.3.13 and 8.x-2.41. Merchants reported fraudulent orders on live stores, some priced at $0.01. If you run Drupal Commerce, upgrade now, update the companion modules at the same time, then audit recent orders, because a patch does not undo an order that was already altered.

What happened

The Drupal Security Team published SA-CONTRIB-2026-254 on 28 October and rated it Highly critical, 21 out of 25 on Drupal's own scale. The advisory says the module does not adequately protect certain routes and entity fields, and that the resulting bypass may financially harm the site vendor. It names no specific route or field. It does state that the flaw is being exploited in the wild and tells sites to audit their orders for inconsistencies.

Centarro, the company that maintains Drupal Commerce, added the operational detail in a maintainer post published in consultation with the security team. It received two reports of attempts to place fraudulent orders. Both came from merchants who noticed suspicious activity on their own live stores, not from researchers testing the platform. The reports included orders with obviously wrong prices such as $0.01, and also orders at normal prices.

The wording on scale differs between the two statements. Drupal says "actively exploited". Centarro says it looked for broader abuse with the security team and, at the time of its post, did not believe the activity was scripted or had spread beyond the initial sites. Treat that as a point-in-time assessment. No indicators of compromise have been published, and exploitation tooling can change quickly once a patch is public.

Who is affected

Any site running the contributed Commerce Core module (machine name commerce) on a vulnerable release. This is separate from Drupal core, so a current Drupal core version tells you nothing about your exposure.

Commerce Core 3.x: 3.0.0 through 3.3.12 are affected. The fix is 3.3.13, which works with Drupal 10.3 and later or Drupal 11.
Commerce Core 8.x-2.x: all releases before 8.x-2.41 are affected. The fix is 8.x-2.41, which works with Drupal 9.3 and later or Drupal 10.

Centarro says exploitation has been theoretically possible since 8.x-2.18 (May 2020) on sites using the JSON:API module, and since 8.x-2.25 (June 2021) on all others. Full-stack and headless stores are both exposed, through different attack vectors. Sites that have sold through Commerce for years therefore have a long period to consider when they review their records.

CISA has not listed the flaw: CVE-2026-118539 was absent from the KEV catalog as of version 2026.11.04. Do not read that as a lower priority. The vendor's own statement of exploitation is the signal here, and KEV entries often lag vendor disclosures.

How CVE-2026-118539 works

The CVE record, published on 30 October with Drupal as the CVE Numbering Authority, classifies the flaw as CWE-862, Missing Authorization. An independent analysis of the patch by Ostorlab describes the root cause in more detail: Commerce entities had access control at the entity level but no separate control on individual fields. An account allowed to edit an object it owned could also change fields on that object that it should never have controlled.

On orders and order items, the fields now restricted include ownership, state and money values such as totals, unit prices and adjustments. Ostorlab says the fix adds a per-entity list of restricted fields, enforced by access handlers before a write is accepted. The same releases require a commerce administration permission on order admin routes, limit coupon autocomplete to accounts that can administer promotions, and stop a deletion from removing entities that belong to someone else. If this pattern is new to you, our explainer on what field-level authorization is and why entity checks fall short covers it.

The sources differ on who can reach the flaw. Drupal scores it as needing no authentication. The CVE record also carries a CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) in its Authorized Data Publisher entry. Ostorlab's analysis says the write paths it examined needed an account, though a customer with update access to their own cart needed no commerce permission at all. A store that allows customer registration gets little comfort from that distinction. The gap between vendor ratings and CVSS is no reason to delay either: a medium CVSS score does not change the fact that the vendor reports fraudulent orders on live stores.

Commerce Stripe has a separate problem in the same release cycle. SA-CONTRIB-2026-263 (CVE-2026-118558, Critical, 15 out of 25) covers a missing CSRF token in the Stripe Connect authorization redirect. An attacker who tricks an administrator into clicking a crafted link could mark an order as paid without payment. Versions 2.0.0 up to but not including 2.2.3 are affected, and 8.x-1.x is not.

What to do now

Start with the Commerce Core upgrade. Ostorlab gives these Composer commands, and Drupal's release pages confirm the fixed versions. Use the line that matches your branch:

composer require 'drupal/commerce:^3.3.13' --with-all-dependencies
composer require 'drupal/commerce:^2.41' --with-all-dependencies

Run your normal update workflow and clear caches. Reapply any custom patches, since both branches changed. The release pages list six advisories fixed together (SA-CONTRIB-2026-254 through 259). Then work through the rest:

Update the companion modules at the same time. Centarro lists security releases for Commerce API, Commerce License, Commerce Shipping and Commerce Stripe. Check each project's release page for the version that applies to you.
Set JSON:API to read-only if you do not need writes. Centarro recommends this for sites that do not need update operations. Drupal's JSON:API documentation places the setting at /admin/config/services/jsonapi. It reduces exposure but does not replace the upgrade: Ostorlab notes that the coupon autocomplete and deletion issues do not depend on JSON:API.
Audit recent orders. Centarro's four checks look for placed orders with no payment, orders marked paid with no payment records, prices no promotion explains, and adjustments your staff did not add. It also publishes SQL queries for each. Our walkthrough on how to audit Drupal Commerce orders for fraud puts them in a working sequence.
Hold fulfillment until payment is confirmed. Centarro is direct on this: checkout completion stages an order for fulfillment and is not proof of payment. See why you should verify payment before fulfillment for how to build that release control.

What to watch next

Three things would change the risk picture: published indicators of compromise, evidence of scripted exploitation, and a KEV listing. Also check Drupal's advisory page for revisions, because Centarro describes its list of order checks as not exhaustive.

Longer term, 8.x-2.x sites have a deadline of their own. Centarro says support for that branch ends when Drupal 12 is released and recommends moving to 3.x as soon as possible. Ostorlab also warns that contributed modules adding their own reference fields must lock those fields down separately, so review custom and third-party Commerce code against the same pattern.

This is the second commerce platform flaw on our recent patch list, after Adobe Commerce PolyShell CVE-2026-48356. Unlike that file upload bug, this one can leave no web shell or other artifact for a scanner to find. The evidence sits in your order data.