Drupal Commerce Core Access Bypass Is Being Exploited

Drupal Commerce Core access bypass is being actively exploited, according to Drupal’s 28 October security advisory. Store teams should install Commerce Core 8.x-2.41 or 3.3.13, based on their branch, and audit orders for inconsistencies. Updating Drupal core alone does not establish that the Commerce module has been fixed.

Last checked: 29 October 2026. Drupal published the advisory on 28 October 2026.

The notice concerns the contributed Commerce Core project, whose machine name is commerce. It supports shopping carts, checkout forms and commerce APIs. This article follows advisory SA-CONTRIB-2026-254, rather than treating every Drupal installation as an affected store.

Why the Store Team Needs to Join the Patch Work

Drupal says certain routes and entity fields lack sufficient protection. The resulting access bypass may cause financial harm to the merchant. The advisory calls for both an update and an order audit, so installing code is only one part of the response.

Drupal rates the issue Highly critical at 21 out of 25. That is its own security risk scale, rather than a CVSS score. Its published rating marks authentication as None and target distribution as All; Drupal’s scale defines these as anonymous access and all module configurations.

The advisory identifies the vulnerability as CVE-2026-118539. Its public CVE Program record was unavailable at our 29 October check, so the identifier here is attributed to Drupal. The product, advisory and fixed releases provide the basis for action while that record is checked again.

Start With the Commerce Branch, Then Choose the Release

Read the installed drupal/commerce version from the site’s deployment records and package inventory. Compare it with the code serving the store, rather than relying on a planned update. Drupal’s advisory gives two affected ranges:

• Commerce versions below 2.41: the advisory directs users to 8.x-2.41.
• Commerce 3.x from 3.0.0 up to, but excluding, 3.3.13: update to 3.3.13.

The release pages give different Drupal core requirements. Commerce 8.x-2.41 supports Drupal ^9.3 || ^10; Commerce 3.3.13 supports ^10.3 || ^11. Check those constraints before choosing a package, and follow the release notes for the site’s existing branch. The advisory’s range is not a promise that every older site can upgrade directly to that release.

This is separate from the earlier Drupal core Field UI vulnerability. A core update for that issue is not proof that this Commerce module is fixed. Track the component and its version in the change record, as part of the vulnerability management cycle.

Run the Update as a Controlled Store Change

Drupal’s module-update guide calls for a full-site backup and a test in a development environment before updating a live site. Read the module-specific release notes first. Its process then covers maintenance mode, new code, required database updates and a cache clear.

After deployment, confirm that the running Commerce code matches the selected fixed release. Review the site log for update errors, as Drupal’s guide recommends. Our patch management explanation covers why installing an update and verifying the result are distinct tasks.

The deployment and order-review checks here are a suggested response workflow based on Drupal’s notice and documentation. We have not tested an exploit or run a store upgrade. Keep any unresolved dependency or deployment failure open until the actual serving code is verified.

Use Order Records to Investigate Inconsistencies

Drupal Commerce lists placed orders at Commerce > Orders, under /admin/commerce/orders. The order page shows items, totals, customer and billing details, and payments. Carts appear separately on the Carts tab, so a review limited to placed orders does not cover both views.

As a practical audit, compare questionable order items, quantities, prices and payment records with the store’s expected transaction history. These are review points drawn from the documented order fields, not published indicators of this exploit. An unusual amount alone does not prove that the vulnerability was used.

The Commerce payment documentation distinguishes an authorization from a captured payment. Review the Payments tab and the matching payment-provider record before treating an order as paid. A legitimate manual edit or partial payment also needs context, so involve store operations when interpreting discrepancies.

Keep suspicious records and the reason for each finding with the incident record. Record what was checked and what remains unresolved; a clean sample cannot prove that every order is intact. For the wider retail workflow, our e-commerce cybersecurity guide connects this response with payment protection and incident planning.

For follow-up validation in a development copy, OWASP’s business logic validation guide calls for checks on the server as well as the frontend. Its payment testing guide covers price integrity at the gateway handoff. Those are broader test goals, not a claim about this exploit’s unpublished route.

Keep the Two Completion Tests Separate

The first completion test is a verified Commerce update. The second is the order audit that Drupal requests because exploitation is active. Closing the patch ticket without the audit would leave the merchant’s financial records outside the response.

Drupal’s notice does not name an attacker, an exploit route or a number of compromised stores. It also does not describe remote code execution. Base the next action on the published module scope and order-review guidance, and revisit this page when Drupal changes the advisory or adds technical detail.