Drupal Commerce Core CVE-2026-118539: A Core Update Won’t Save You

Drupal says CVE-2026-118539, a highly critical access-bypass flaw in Drupal Commerce Core, is being actively exploited in the wild. Updating Drupal core leaves this module untouched. The advisory's version numbers also need a careful second read before you call your shop patched.

Does your site even run Drupal Commerce Core?

If your store’s cart, checkout or product catalog is built on Drupal, it almost certainly runs Commerce Core. Drupal says the module lets you “sell goods and services to customers through an included shopping cart and checkout form or through decoupled applications via APIs.”

That last clause matters. Shops with a React or mobile frontend that run Drupal only behind the scenes still run Commerce Core, even if nobody has opened the admin in months.

The flaw is CVE-2026-118539. Drupal rates it “highly critical” and says attackers are already using it. The Hacker News reported the advisory on October 30, 2026. Drupal published no CVSS score, but a missing number does not soften Drupal’s own risk rating.

Three quick ways to confirm whether you are in scope:

• Admin UI: under Extend (/admin/modules), look for Commerce and submodules such as Cart, Checkout, Order and Price.
• Composer: the package is drupal/commerce, and composer.lock records the exact installed version.
• Your agency or host: ask for the installed Commerce version in writing. “We keep things updated” is not an answer.

WordPress users should watch for one trap. Commerce is a contributed project installed separately from Drupal core, so a fully updated core can sit on top of a vulnerable Commerce module. Once a module flaw is public and exploited, assume automated scanning will reach your site. Our breakdown of how attackers find exposed websites shows how cheaply that works.

What can unprotected Commerce routes and fields change on a live shop?

Things a visitor or low-privilege account should never touch. A route is an address the site answers, whether a browser page or an API endpoint. An entity field is a piece of stored data, such as a value on an order, a product variation or a price.

Drupal checks access at separate layers: who may reach a route, who may view or edit an entity, and who may read or write a single field. Locking down an admin page does not protect the same operation arriving through another route or an API call. When one check is missing, a request that should be refused goes through.

That is the failure the advisory describes: the module “doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.” The vendor here is the merchant. The risk is to order data, pricing and transaction state rather than to customers’ cards.

Drupal has not said which routes or fields are affected, and the advisory does not claim remote code execution, server takeover, card theft or new administrator accounts. No threat actor, campaign, victim count or indicator of compromise has been published. Dan Puccetti, Marcus Johansson and Robert Snyder are credited with reporting the flaw.

Is Commerce Core 3.3.13 the fix or still vulnerable?

The published details contradict each other, so check Drupal’s own advisory before you call the shop patched.

On both branches, the upgrade target is also the top of the vulnerable range, and The Hacker News report does not explain why. If the ranges mean “up to but not including,” 3.3.13 and 8.x-2.41 are the first safe releases. If they are inclusive, those builds are still vulnerable and the fix is a newer release.

• Read the solution section of Drupal’s security advisory for Drupal Commerce yourself.
• If your branch has a release newer than 3.3.13 or 8.x-2.41, install the newest one.
• Record the advisory identifier and the verified package version in your change ticket.

Don’t jump branches during an emergency. Moving from 2.x to 3.x is a migration project. Patch the branch you run now, then plan the move.

Step by step: how to update Drupal Commerce Core and finish the job

1. Preserve evidence first. Before changing anything, export web server access logs, Drupal’s Recent log messages and a database snapshot. If records were altered, you need the before picture.
2. Back up code and database so you can roll back if the update breaks checkout.
3. Update the module. On Composer sites, update drupal/commerce and its dependencies to the verified fixed release, then commit the new composer.lock.
4. Run database updates and rebuild caches. Run update.php or drush updatedb, then drush cache:rebuild. Skipping these can leave the update half done.
5. Confirm the running version on production. Check the Status report and composer.lock on the live server, not just staging.
6. Test checkout end to end. Place a real low-value order, refund it, and confirm payment gateway callbacks still arrive.
7. Reconcile business records for the whole period you ran a listed version (see below). A new version number does not close the incident.

Can a firewall stand in for the update? Only partly. A website firewall cuts opportunistic scanning and can restrict who reaches admin and API paths. Drupal has not published the affected routes or request patterns, so nobody can write a precise virtual patch yet. Use the firewall to shrink exposure while you update. It is not the fix.

What should headless and API storefronts verify after the module update?

Check that the backend your frontend actually calls is the one you patched. Decoupled shops often run several Drupal instances: the production API, an old staging copy still reachable on a subdomain, perhaps a regional backend nobody remembers. Each of those backends is in scope.

• List every hostname your app, frontend or partner integrations call, and check the Commerce version on each.
• Patch or take offline any forgotten clones and preview environments that are still internet-facing.
• Revoke unused API keys and OAuth clients, and limit the rest to the permissions they need.
• Purge CDN or edge caches so stale API responses aren’t served after the update.

A custom frontend adds no protection here, because authorization happens in Drupal. If Commerce Core skips a check, the frontend never gets a vote.

Which order, price, and payment records deserve a manual look?

Start with the records that hold money. Drupal hasn’t described how the flaw is being exploited, so this review is a precaution, not proof you were hit. But “financial impact on the vendor” tells you where to look.

• Orders: totals that don’t match their line items, or orders marked paid with no matching transaction at your payment provider.
• Prices: product variation prices that changed with no matching admin edit in the logs.
• Promotions and coupons: new discounts, extended expiry dates or raised usage limits.
• Payments and refunds: Drupal’s payment records compared with your gateway dashboard for the whole period you ran a listed version.
• Customer accounts: unexpected role or data changes on store users.

Practitioner’s note: for this bug, reconciliation beats log searching. Export the last 30 to 60 days of orders and compare them against the processor’s settlement report. Mismatches jump out. With no affected URLs public, searching for one suspicious path proves nothing either way. If revisions are enabled on products or orders, check for edits by anonymous or unexpected accounts.

If records look altered on a site that ran a listed build, treat it as a cleanup case: keep the evidence, correct the data, rotate admin and API credentials, and scan for anything else left behind. Our hack recovery cases show how often a quick patch job turns up a second problem.

Is this the same as PHP2Shell, or do I need two fixes?

You need two fixes. PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two CVSS 9.2 flaws in the PHP runtime itself. CVE-2026-118539 lives in a Drupal module. Updating one does nothing for the other, and every Drupal shop runs on PHP.

As of October 25, the share of organizations significantly affected by PHP2Shell had declined to 52.1%, by the count of Wiz, which Google owns. The report does not give the earlier figure or define the metric. Wiz splits the activity it sees into two clusters:

• Real PHP2Shell attempts: traffic that uses the actual exploit mechanism and matches public proofs of concept.
• PHP2Shell in name only: branded tools unrelated to the two CVEs. They rely on session poisoning plus a separate local file inclusion bug in the target application.

Upgrading PHP will not fix that application bug, so find out which kind of traffic you are seeing. Wiz researchers Yaara Shriki, Shahar Dorfman, Alma Blachsan and Yaron Samuel found that “triggering memory exhaustion alone is not enough to complete the exploit chain,” because PHP builds, memory limits and worker behavior vary. That isn’t a reason to wait. It means attackers are still working on reliability.

What we still don't know

Drupal hasn’t said when exploitation began, how widespread it is, who is behind it, or which routes and fields are affected. The report also gave no release dates for the fixed builds.

That gap favors the attacker, who already knows which requests work while defenders have no indicators to search for. Patching the module and reconciling your records are the only steps that don’t depend on unpublished details. After that, keep watching. Continuous website monitoring flags unexpected file and content changes, so the next surprise shows up within hours instead of at month-end reconciliation.

FAQ

What is CVE-2026-118539 in Drupal Commerce Core?

A missing-authorization flaw: Commerce Core does not sufficiently protect certain routes and entity fields, allowing an access bypass that may financially impact the store. Drupal rates it highly critical and says it is actively exploited.

Is Commerce Core 3.3.13 the fixed version or still vulnerable?

Reports list 3.3.13 as both the top of the vulnerable range and the 3.x upgrade target. Check Drupal's official advisory and install the newest release on your branch.

Does updating Drupal core fix the Commerce Core flaw?

No. Commerce is a separately installed contributed project, usually the drupal/commerce Composer package, and needs its own update followed by database updates and a cache rebuild.

Am I affected if my store uses a headless or API frontend?

Yes, if the backend runs a listed Commerce Core version. Authorization happens in Drupal, not in your frontend.

Found records that don’t add up, or not sure your Drupal store was patched in time? SiteGuarding handles hack cleanup, firewall setup and ongoing monitoring: choose a protection package for your site.