Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

Drupal Commerce Core Authorization Bypass Is Being Exploited in the Wild

Drupal has confirmed that CVE-2026-118539, a highly critical missing-authorization flaw in the Commerce Core module, is under active exploitation. Shops on the 2.x and 3.x branches need to move to 8.x-2.41 or 3.3.13 now and check their logs.

4T4Tify Team4Tify
Oct 30, 2026·5 min read
Drupal Commerce Core Authorization Bypass Is Being Exploited in the Wild

Drupal Commerce Core Authorization Bypass Is Being Exploited in the Wild

Online shops built on Drupal have a patching job to do today. The Drupal security team has confirmed that a "highly critical" access-control weakness in the Commerce Core module, tracked as CVE-2026-118539, is already being exploited in the wild.

What happened

Commerce Core is the module that turns a Drupal site into a store. It provides the shopping cart and checkout flow, and it also exposes commerce data to decoupled front-ends through APIs. The flaw is a case of missing authorization: certain routes and entity fields are not sufficiently protected, so requests that should be rejected are processed instead. Drupal describes the result as an access bypass that may have a financial impact on the merchant, which in a commerce context means orders, prices or customer data being read or changed by someone with no right to touch them.

Affected versions are every Commerce Core release before 8.x-2.41 on the legacy branch and every 3.x release before 3.3.13. No CVSS score has been published yet, but Drupal's own "highly critical" rating sits near the top of its severity scale.

Drupal has stated that exploitation is already happening but has not shared who is behind the activity, how widespread it is, or what attackers do after a successful bypass. Treat that silence as a reason to move faster, not slower.

Why it matters

Three things make this one uncomfortable:

  • Money is the target. An authorization bypass in a checkout system is immediately monetisable: price tampering, order manipulation, or quiet harvesting of customer and payment-related records.
  • The attack surface is often invisible to the shop owner. Decoupled storefronts and headless integrations talk to Commerce Core over APIs that rarely get the same monitoring as the public pages.
  • Commerce sites update slowly. Stores avoid touching production in busy periods, and the end of October is the start of peak season for many retailers. Attackers know this.

The wider PHP picture

The Drupal advisory lands while PHP itself is under fire. Two critical bugs in the PHP runtime, CVE-2026-109618 and CVE-2026-109619 (both CVSS 9.2, collectively known as PHP2Shell), are also seeing exploitation attempts. Available exposure data suggests that just over half of organisations (52.1%) were still significantly affected as of 25 October. That is lower than earlier in the month, but still far too many.

Observed activity splits into two groups: attempts that follow the public proof-of-concept exploit mechanism, and opportunistic "PHP2Shell"-branded tooling that actually relies on session poisoning and a separate local file inclusion bug rather than the new CVEs. Reliable exploitation is harder than the hype suggests, because differences in PHP builds, memory limits and worker behaviour can break later stages of the chain. That is a delaying factor, not a defence. Since Drupal runs on PHP, a shop that is behind on both is doubly exposed.

What to do

  1. Update Commerce Core now. Sites on the 3.x branch should move to 3.3.13; sites on the older branch should move to 8.x-2.41. Schedule the maintenance window today, not next sprint.
  2. Patch PHP as well. Confirm your runtime carries the fixes for CVE-2026-109618 and CVE-2026-109619, including on staging and build servers.
  3. Review commerce logs for the exploitation window. Look for unauthenticated or low-privilege requests hitting order, cart, payment or product routes and API endpoints, and for unexpected changes to prices, promotions or order states.
  4. Assume tampering until proven otherwise. If you cannot rule out abuse of the exposed fields, re-validate recent orders and rotate any credentials or API keys stored in commerce configuration.
  5. Inventory every Drupal instance. The forgotten staging shop or regional storefront running an old Commerce Core is the one most likely to be hit.

Flaws like this are exactly what continuous vulnerability scanning is built to catch early. Our scanning identifies outdated Drupal modules and PHP versions across your web estate and flags them against actively exploited CVEs, so a "highly critical" advisory becomes a prioritised ticket instead of an incident report.

SHARE