Drupal Commerce Access Bypass Under Attack: Patch and Audit

Drupal has confirmed active exploitation of CVE-2026-118539, a highly critical Drupal Commerce access bypass that lets requests reach store routes and data they should never touch. Updating the module closes the hole, but you also need to check whether anyone changed your orders, prices or checkout settings while it was open.

How the Drupal Commerce access bypass can cost you money

CVE-2026-118539 is a missing-authorization flaw in Drupal Commerce Core, the contributed module that handles the money: the shopping cart, the checkout form and the APIs that headless storefronts call. Drupal’s security team rates it “highly critical.”

The advisory sums up the bug in one sentence: the module “doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.” Drupal is not warning about a defaced homepage or a leaked customer table. It is warning that the merchant can lose money, and no malware or server takeover is required. The store only has to accept a request it should have refused.

A route is a URL or API endpoint the module responds to, such as a checkout step or an order operation. An entity field is one piece of stored data: an order total, a line item, a status, a profile value.

Drupal checks access to routes and access to fields as separate layers, so reaching a route does not automatically entitle the caller to read or write every field behind it. If either layer skips its permission check, a session with the wrong role gets processed as if it had the right one.

The defect class is well documented. MITRE catalogs it as CWE-862, Missing Authorization, and broken access control holds the top spot (A01) in the 2021 edition of the OWASP Top 10. In our pentests it is among the bugs automated scanners miss most often, because the vulnerable response looks like a normal, successful page.

Drupal says the flaw is being “actively exploited in the wild” but has not said which routes or fields are affected, what access an attacker needs to start with, who is behind the activity or how many stores were hit. No campaign name, threat actor or indicators of compromise have been published.

The advisory also carries no CVSS score. Don’t read that as low risk: “highly critical” is Drupal’s own top severity label and does not depend on a CVSS number. Dan Puccetti, Marcus Johansson and Robert Snyder are credited with reporting the issue, and The Hacker News covered the advisory on October 30.

Which Commerce Core release should you actually install?

Install the release the current Drupal advisory names as fixed for your branch, and confirm it yourself, because the version numbers in circulation contradict each other. As reported, the affected ranges are Commerce Core 0.0.0 through 2.41 and 3.0.0 through 3.3.13, while the recommended upgrades are 8.x-2.41 for the older line and 3.3.13 for the 3.x line.

Both upgrade targets fall inside the ranges listed as vulnerable. Either the ranges were meant to read “before 2.41” and “before 3.3.13,” or the fixed releases are later than the ones quoted. The reporting doesn’t resolve this, and a store owner should not have to guess.

To settle it for your own site:

1. From the Composer project root, run composer show drupal/commerce and write down the installed version.
2. Open the Commerce Core advisory and the project’s release page on drupal.org. Compare your version with the fixed release listed there today.
3. If the advisory now names a release above 3.3.13 or 8.x-2.41, install that one. If it confirms those two as fixed, make sure you are actually on them.
4. In the Drupal admin, open Reports, then Available updates. Commerce should show no pending security update.

Teams that patch on autopilot fall into one trap: Commerce Core is maintained and released separately from Drupal core, so a fully patched core install can still run a vulnerable Commerce module. If your host or agency says it “keeps Drupal updated,” ask which Commerce version is installed.

Headless stores are in scope as well. Drupal says Commerce Core sells “through an included shopping cart and checkout form or through decoupled applications via APIs.” If a React or mobile front end talks to a Drupal Commerce back end, you need to patch the back end.

Exploitation is already confirmed, so treat this as an emergency change, not next month’s maintenance.

What should you audit on the store after the update?

Audit the money trail: orders, prices, promotions and the accounts that can change them. An access bypass rarely leaves a web shell or a strange file behind. What it leaves are ordinary HTTP requests and commerce records that look legitimate until you compare them with what your staff actually did.

Copy the logs before you upgrade. Save web server, reverse proxy, PHP and Drupal watchdog logs, along with a database snapshot, before cache clears or log rotation can wipe them. This takes minutes, not hours. Then review, going back as far as your logs reach:

• Orders: state changes nobody on staff made, such as orders marked paid with no matching gateway record, and orders edited by anonymous or low-privilege sessions.
• Totals and prices: line items that don’t match the catalog price at the time, and product prices changed without a staff edit.
• Promotions: new discounts, coupons used beyond their limits, unusual stacking.
• Customer profiles: billing or shipping addresses changed after checkout, or by sessions that don’t own the profile.
• Checkout and payment configuration: gateway, tax and checkout flow settings, compared against your last configuration export.
• Users and roles: new administrators, and roles that gained Commerce permissions.

Drupal hasn’t said which objects attackers abused, so treat this list as places to look, not confirmed indicators. Reconcile your order list against your payment processor’s statement for the same period. A mismatch in either direction needs an explanation.

A practitioner’s note from our engagements: the most common access-control mistake on Drupal stores is assuming that hiding a menu link blocks access to the page behind it. It doesn’t. Anyone can request the URL directly.

On a staging copy (never the live shop), request the same Commerce pages and API endpoints directly as an anonymous visitor, a customer and an admin. If the customer session can see or change something meant only for admins, you have a gap, whether or not it is this CVE.

Two cautions cut the other way: quiet logs don’t prove the store was untouched if logging was thin or retention was short, and normal traffic to Commerce endpoints is not evidence of an attack.

If anything looks off, reset passwords for every Drupal and Commerce admin and rotate the API keys used by decoupled front ends and integrations. To catch future file and code changes you didn’t make, our antivirus website protection keeps watching after the cleanup.

How is this different from a card skimmer on checkout?

It is a different attack, and nothing published so far suggests it copies card numbers. A skimmer is injected JavaScript that runs in the shopper’s browser and captures what they type into the payment form. CVE-2026-118539 is a server-side permission gap that can let someone touch data the vendor controls. Drupal names no payload, malware family or injected script.

An attacker with unauthorized access to store data could still reuse it for something else later, and with the activity details unpublished, the advisory alone can’t rule that out.

Patching Commerce also does nothing about scripts your checkout loads from other servers: in the Convertr checkout skimmer hidden in a shared Plausible tracker, every merchant ran card-stealing code because each one trusted the same third-party analytics file. List every analytics, chat, testing and payment script on your checkout, note who maintains each one, and remove any you can’t vouch for.

Is this connected to the PHP2Shell attacks?

No. The Hacker News reported the Drupal advisory alongside new PHP2Shell data, but they are unrelated bugs. PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2, in the PHP interpreter itself.

Google-owned Wiz said that as of October 25, 52.1% of organizations in its telemetry were still significantly affected by PHP2Shell, down from a higher, unspecified earlier level. That figure describes Wiz’s own data, not half the web.

Wiz also found that public proof-of-concept code is unreliable, because “triggering memory exhaustion alone is not enough to complete the exploit chain.” A second cluster of “PHP2Shell-branded” tools skipped the PHP bugs entirely and relied on session poisoning plus an unrelated local file inclusion flaw.

The takeaway for a Drupal store: patching Commerce Core does not patch PHP, and patching PHP does not patch Commerce Core. You need to check both.

When should you bring in a cleanup instead of only patching?

Bring in outside help when your audit turns up anything your team can’t explain. The update closes the hole, but it doesn’t undo whatever happened while the hole was open, and Drupal has confirmed exploitation without saying how widespread it is.

Treat the site as possibly compromised if:

• Orders, prices or discounts changed without a staff action.
• An admin account or role appeared that nobody created.
• Checkout or payment settings differ from your last known-good export.
• Your logs don’t cover the whole period the store ran an affected release.

Work in this order: copy logs and snapshot the database, patch right away, then look for tampered commerce data and new privileged users, and finally re-secure the admin accounts. A cleanup covers what a module upgrade doesn’t: reconciling records, finding backdoor accounts, and checking files and the database for anything added. Our hack recovery cases show what that work looks like.

With no IOCs published, a web application firewall and continuous monitoring are your realistic way to spot the next probe early. Our website protection package includes both.

FAQ

Does CVE-2026-118539 have a CVSS score?

Not yet; the advisory lists none. Drupal labels it “highly critical,” the highest rating on its own scale, so a missing number is no reason to wait.

Do I have to update Drupal core as well as Commerce Core?

Updating core alone won't help here. Commerce Core ships separately as a contributed module, so you must upgrade the Commerce module itself. Keeping core current is still good practice.

Is Commerce Core 3.3.13 the fixed release?

Possibly, but the reporting lists 3.3.13 both as the fix and as the top of the affected 3.x range. Check the current advisory on drupal.org for the confirmed fixed release before you consider the store safe.

What store data should I review after patching?

Start with order status changes, totals and line-item prices, then coupon use, customer profile edits, checkout and payment settings, and any new admin users or roles. Match your orders against your payment processor's records.

Is this the same issue as PHP2Shell?

No. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) sits in the PHP interpreter, while CVE-2026-118539 sits in the Commerce module. Each needs its own patch.

How do I know if my Drupal shop was already hit?

Drupal has published no indicators, so the evidence lives in your own records: changes to orders, prices or settings that no staff member made. If you find any, or your logs don't cover the exposure window, treat the site as possibly compromised.

If your Commerce store ran an affected release and the audit raises questions, our team can clean it up and lock it down. Start with a website protection package that combines a firewall with continuous monitoring.