CRITICAL: Drupal Commerce Core Access Bypass Under Active Exploitation

If you run a Drupal storefront, your weekend plans just changed. The Drupal Security Team published SA-CONTRIB-2026-254 on October 28, warning that Commerce Core, the module that turns a Drupal site into an online store, contains an access bypass flaw that attackers are already exploiting. The bug is tracked as CVE-2026-118539, and Drupal's own advisory carries the kind of sentence nobody wants to read about the module that handles their money. "This vulnerability is being actively exploited in the wild."

That alone would make this a drop everything situation. What makes it worse is the second line of guidance from the security team, which tells site owners to audit their orders for inconsistencies. That is not the usual "patch at your earliest convenience" language. That is Drupal telling you the attack may already have happened and the evidence is sitting in your order history.

What the flaw actually is

Commerce Core is the foundation of the Drupal Commerce ecosystem. It provides the shopping cart, the checkout flow, product and order entities, and the APIs that decoupled storefronts use when the frontend is a React or mobile app talking to Drupal behind the scenes. According to the project page, 42,002 sites report using it, and that number only counts sites that phone home with usage statistics. The real install base is almost certainly larger.

The advisory describes the problem in deliberately sparse terms. The module "doesn't sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor." Drupal has not published which routes or which fields, and given that exploitation is live, that restraint is reasonable. Reading between the lines is not hard, though. In a commerce system the entity fields that matter financially are things like order totals, line item prices, adjustments, discounts, payment state, and order status. A missing authorization check on any of those, reachable through a route that a regular customer or even an anonymous visitor can hit, is how you end up shipping a laptop to someone who paid a dollar for it, or marking an unpaid order as complete.

Drupal scored the issue "Highly critical" at 21 out of 25 on its own risk calculator, with the vector AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All. Translated out of Drupal's notation, that means the attack has no meaningful complexity, requires no authentication or privileged role, affects some confidentiality and some integrity of the data, has a working exploit in circulation, and applies to all default configurations rather than some niche setup. There is no CVSS score attached to the CVE record yet, so any scanner that sorts by CVSS is going to rank this lower than it deserves. Do not let a blank score field talk you out of treating this as critical.

The vulnerable range covers essentially every supported release line. Sites on the 8.x-2.x branch are affected on anything before 8.x-2.41, and sites on the 3.x branch are affected from 3.0.0 up to but not including 3.3.13. The fixed releases, Commerce Core 3.3.13 for Drupal 10.3 and 11 and Commerce Core 8.x-2.41 for Drupal 9.3 and 10, both shipped on October 28 alongside the advisory.

Credit for the discovery goes to Dan Puccetti, Marcus Johansson, and Robert Snyder. The fix came from a team that includes longtime Commerce maintainers Jonathan Sacksick and Ryan Szrama along with Lee Rowlands of the Drupal Security Team, and coordination ran through a long roster of security team members including Greg Knaddison, Damien McKenna, and Jess (xjm). When that many people sign an advisory for a contributed module, you can safely assume it was taken seriously.

What exploitation looks like

Neither Drupal nor The Hacker News, which reported the exploitation on October 30, has shared details about who is behind the attacks or how widespread the campaign is. That gap is frustrating, but the advisory's language gives defenders enough to work with. When a security team tells you to look at orders rather than to look for webshells, the attacker's goal is fraud, not persistence. Think manipulated carts, altered prices, discounts applied that should never apply, orders flipped to paid or completed without a matching payment transaction, or customer order data viewed by someone who should not see it.

This is also exactly the kind of bug that gets mass exploited quickly once a patch is public. Commerce Core is open source, the fix is a diff away for anyone who wants to reverse engineer it, and an access bypass on a route is about as easy to weaponize as vulnerabilities get. A Python script and a list of Drupal Commerce sites pulled from a search engine is all the infrastructure an attacker needs. If you are still unpatched today, assume you have been probed.

There is a reasonable chance this will not show up as a dramatic outage. Fraud through business logic tends to be quiet. The site keeps working, the dashboards stay green, and the first sign of trouble is a finance team member asking why the payment processor's settlement report does not match the order ledger. That is why the audit guidance matters so much.

What to do right now

Patching is the first and most important step. Sites on Drupal 10.3 or Drupal 11 should update to Commerce Core 3.3.13 with Composer by running composer require 'drupal/commerce:^3.3' and then running database updates and clearing caches. Sites still on the 2.x line should move to 8.x-2.41 with composer require 'drupal/commerce:^2.41'. If your site is running something older than Drupal 9.3, you have a bigger problem than this advisory, and you should be planning a migration rather than hoping a backport appears.

If you cannot patch immediately, and I know some of you are staring at a change freeze or a contractor who built the store three years ago and has not answered email since, consider temporarily restricting access to the store's API endpoints at the web application firewall or reverse proxy, especially JSON:API, REST, and any Commerce cart API routes that a headless frontend does not strictly require. That is a stopgap and not a fix, because Drupal has not published the exact routes involved, but it shrinks the attack surface while you get the update scheduled.

Then do the audit Drupal asked for. Reconcile completed orders against your payment gateway's records for at least the past several weeks and flag any order marked paid without a matching captured transaction. Compare order totals against the sum of their line items and adjustments, and look for prices that do not match the product catalog at the time of purchase. Review promotions and coupons for redemptions that look out of place, and check for orders whose state changed without a corresponding admin action in the logs.

On the detection side, pull your web server and Drupal watchdog logs and look for unusual PATCH or POST requests against commerce order, order item, and cart endpoints, particularly from anonymous sessions or from customer accounts touching orders that are not theirs. Spikes in API traffic from a handful of IP addresses, or requests to entity routes that your storefront never normally calls, deserve a closer look. If you find manipulated orders, preserve the logs before rotating anything, because your payment processor and possibly your cyber insurance carrier will want to see them.

Finally, remember that Commerce Core rarely lives alone. Payment gateway modules such as Commerce PayPal and Commerce Realex have had their own access bypass advisories this year, and a full composer update review of the Commerce stack is worth the time while you are already in there.

The bigger picture

E-commerce platforms keep getting hit for the same reason banks kept getting robbed. That is where the money is. A flaw in a content management system usually means defacement or a foothold. A flaw in the cart means direct financial loss, chargebacks, inventory walking out the door, and a very awkward conversation with your payment processor about PCI DSS obligations. Small and midsize retailers running Drupal Commerce often do not have a security team, and many of them have no idea which version of a contributed module is holding up their checkout page.

The fix is out, the exploit is circulating, and Drupal has told you to check your books. Patch today, reconcile your orders this week, and stop trusting the absence of a CVSS score as a sign that something is not urgent.

MSP angle

Any client running a Drupal or other open source storefront is a candidate for a fast patch and order reconciliation engagement this week, and that conversation opens the door to recurring managed patching for web applications and WAF services. It is also a strong case for selling a quarterly e-commerce security review that covers module inventory, payment flow integrity checks, and log monitoring, since most small retailers have none of it today.