Drupal says Commerce Core access bypass is already hitting live shops

Drupal’s security team has flagged a highly critical access-bypass bug in Commerce Core and said attackers are already using it. The identifier is CVE-2026-118539. The module is the shopping-cart and checkout layer for Drupal stores, including API-driven fronts. Public counts put it on more than forty thousand sites. The failure is missing authorization on certain routes and entity fields. The vendor’s own sentence is that the result may financially impact the merchant.

BleepingComputer reported the warning on October 30, 2026. The Hacker News ran a parallel account the same day. Affected ranges in those write-ups cover Commerce Core through the 2.x line up to 2.41 and the 3.x line up to 3.3.13. Drupal’s instruction is to move immediately to Commerce Core 3.3.13, or to Commerce Core 8.x-2.41 on earlier branches, and to audit orders for inconsistencies. That second half is not optional color. An access bypass on commerce entities is how orders, prices, and fulfillment state get quietly wrong.

Why an access bypass is a money problem

Remote code execution grabs headlines. Authorization gaps empty carts and rewrite invoices. An unauthenticated caller who can reach a protected route does not need a stolen admin cookie. They need the site to still be on a vulnerable Commerce Core build. For a university bookstore, a Fortune 500 brand shop, or a small merchant on shared hosting, the blast radius is revenue, customer PII attached to orders, and the integrity of what the warehouse ships.

This desk will not list the unprotected routes, the field names, or a request sequence that proves the bypass. Merchants do not need a recipe. They need the patched module and a review of what already landed in the order tables. If your storefront is decoupled and talks to Commerce over APIs, treat those endpoints as in scope. The CMS theme is not the boundary.

What store operators should do now

Upgrade Commerce Core to the builds Drupal named. Confirm the module version in the extend list or with your composer lockfile. Then pull recent orders and look for the boring anomalies: totals that do not match catalog rules, statuses that flipped without a payment event, customer records attached to activity nobody recognizes. Export what you need for finance before you clean anything.

Put a temporary rule on the edge if you cannot patch in the next change window. Rate-limit anonymous traffic to commerce paths. Require authentication where the product allows. That is triage, not a substitute for the module bump. After the patch, keep watching. Drupal’s recent calendar already included SQL injection and remote-code issues that drew CISA attention. Commerce Core’s active exploitation notice is the current ticket.

If you run many Drupal properties, inventory which ones actually enable Commerce Core. A content site without the module is out of this particular blast radius. A forgotten promo shop with an old 2.x build is not. Patch the money path first.

This briefing relies on public reporting by BleepingComputer and The Hacker News, and on Drupal’s advisory language. It does not include exploit procedures or reproduction steps.