CVE-2026-118539: Drupal Commerce Core Bypass Exploited, No CVSS Score

Drupal says attackers are already exploiting CVE-2026-118539, a missing-authorization flaw in Drupal Commerce Core rated "highly critical" with no CVSS score attached. The reported version numbers disagree about whether 3.3.13 is vulnerable or fixed, so a store can look patched when it is not.

What did Drupal confirm about CVE-2026-118539?

Drupal confirmed three things: its Commerce Core module has an access bypass, the Drupal Security Team rates it highly critical, and attackers are exploiting it in the wild. The Hacker News reported the advisory on 30 October 2026. The bug is tracked as CVE-2026-118539, and its CVSS field reads N/A.

The technical description is one sentence. Per the advisory, the module “doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.” That is a missing-authorization bug, CWE-862 in MITRE’s CWE list: a request reaches code that does real work, and nothing first checks whether the caller may ask for it.

Commerce Core lets a Drupal site “sell goods and services to customers through an included shopping cart and checkout form or through decoupled applications via APIs.” The exposed surface covers classic storefronts and headless builds, where a JavaScript or mobile front end talks to Drupal over an API.

Drupal left out the rest. The advisory gives no description of the exploitation, no victim count, no named actor, no start date and no list of affected routes or fields. It does not say whether an attacker needs an account. Dan Puccetti, Marcus Johansson and Robert Snyder are credited with the report.

Why does a missing CVSS score still put this at the top of the queue?

A missing CVSS score does not lower the priority, because Drupal has already rated the bug on its own scale. “Highly critical” is the top category in the Drupal Security Team’s risk model, which runs separately from CVSS. A blank CVSS field means nobody has filled in that number yet, not that the flaw is minor.

The blank field causes trouble in pipelines that sort by CVSS. A CVE with no score can sink to the bottom of a dashboard or slip past an SLA rule that fires at 9.0. If your scanner or ticketing rules behave that way, override them by hand. Confirmed exploitation plus the vendor’s top rating outweighs any base score.

Drupal’s history argues for speed. After the 2014 Drupalgeddon SQL injection in Drupal 7 core, the security team told owners that sites not patched within about seven hours of the fix’s release should assume compromise. That was a core bug with a more severe exploitation path than an access bypass, so the parallel is about tempo, not impact.

On tempo, this advisory starts from a worse position. It arrived after exploitation had already begun, so the attackers’ window opened before you knew the bug existed.

Which Commerce Core versions does CVE-2026-118539 affect, and is 3.3.13 the fix?

The published numbers do not answer that cleanly, so do not guess. As reported, the affected ranges are 0.0.0 through 2.41 and 3.0.0 through 3.3.13. The same report tells 3.x sites to upgrade to Commerce Core 3.3.13 and older branches to 8.x-2.41.

Those statements cannot both hold if the upper bounds are inclusive, because one release cannot be both vulnerable and the fix. The likeliest explanation is exclusive bounds in the original advisory (“before 3.3.13”) that got flattened in reporting. A later release superseding the named ones is another possibility.

The older branch has the same problem plus a naming wrinkle. 8.x-2.41 is Drupal’s legacy version format for release 2.41 of the 2.x branch, so the same number again sits at both ends: last affected and fixed.

Open the CVE-2026-118539 advisory on drupal.org, read the exact fixed release for your branch, and confirm its release notes mention the security fix. Until then, do not close the ticket at 3.3.13 or 8.x-2.41. If a newer release exists on your branch, take it.

Commerce is also a contributed project, installed through Composer as drupal/commerce, not part of Drupal core. A site that is current on core can still run a vulnerable Commerce release, and an update process that covers only core will never touch it.

What can an access bypass change in a Drupal Commerce store?

An access bypass can change whatever the unprotected routes and fields touch, and Drupal has not said which those are. Routes decide which URLs and API endpoints respond. Entity fields are individual properties on objects such as orders, products, customers and stores.

Drupal checks the two layers separately: permission to reach a route does not by itself grant permission to edit every field on the entity behind it. A gap at either layer produces an endpoint that returns a normal response while doing something the caller should not be able to do.

On a commerce object model, “may financially impact the vendor” points toward outcomes such as these:

• reading or changing orders that belong to someone else
• altering field values that feed totals or order state
• touching store configuration

That list describes the bug class, not a confirmed exploit. The advisory does not say which of these, if any, is in play.

OWASP’s API Security Top 10 (2023) gives two lenses: API1, Broken Object Level Authorization (acting on someone else’s object ID), and API3, Broken Object Property Level Authorization (writing a field you should only read). The “entity fields” wording leans toward API3.

From our engagements: on headless commerce builds, the authorization gaps we find rarely sit on the page a shopper sees. They sit in the API behind it, where a handler checks that the user may update an order but never checks which properties they may set. The UI never sends those fields, so functional QA never notices.

Broken access control and IDOR testing exists to catch exactly this, role by role and field by field. If your store exposes Commerce through an API, scope a separate API penetration test rather than assuming the storefront test covers it.

How do Drupal Commerce store owners check, patch and hunt for compromise?

Work in this order: confirm the version, fix it, then investigate retrospectively. Patching closes the door, but it does not undo anything an attacker already changed.

1. Confirm what you run

• From the Composer project root, run composer show drupal/commerce to get the installed release.
• Run drush pm:list –filter=commerce to list enabled Commerce modules. On multi-site hosts, drush status confirms which site you are inspecting.
• Check composer.lock in version control for every environment, including staging and forgotten regional storefronts.

2. Preserve evidence if anything looks off

• Before maintenance, copy composer.lock and your web-server, PHP-FPM, CDN and WAF logs. If Database Logging is enabled, export /admin/reports/dblog too. It is not a full HTTP audit trail, so the edge logs carry more weight.
• Do not let forensics delay the upgrade by days. Capture what retention would otherwise delete, then patch.

3. Upgrade to the advisory-confirmed release

• Take a backup and deploy the fixed Commerce release the drupal.org advisory names for your branch. Run drush updatedb, then drush cache:rebuild, then check /admin/reports/status for pending updates or errors.
• If you cannot upgrade today, restrict Commerce admin and API routes at the edge: IP allowlists for admin paths, gateway authentication for API consumers. Without the route list, any virtual patch is coarse, so treat it as a holding action, not a fix.

4. Hunt for unauthorized commerce changes

There are no published indicators, hashes or infrastructure to search for, so the hunt looks at the state of your data rather than at signatures.

• Reconcile Commerce orders and totals against your payment provider’s records for the whole log-retention window. A gap between what Drupal says was paid and what the processor settled is the clearest financial signal.
• Review order-status transitions that skipped normal steps, orders edited after completion, and price or product changes no staff member made.
• Audit customer and administrator accounts, roles and permissions for anything new or elevated.
• Correlate anonymous or low-privilege requests to Commerce routes with actual object changes. A 200 response on a Commerce URL proves nothing on its own.

If you find changes you cannot explain, open an incident. Rotate admin credentials and API keys, and bring in your payment provider early.

Is PHP2Shell connected to the Drupal Commerce exploitation?

No source connects them. The Hacker News covered both stories in the same report, but nothing in it ties either PHP2Shell activity cluster to CVE-2026-118539. Keep the two timelines separate.

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two PHP flaws scored CVSS 9.2 each. According to Wiz, now owned by Google, the percentage of organizations significantly affected by PHP2Shell had declined to 52.1% as of 25 October 2026. That figure says nothing about Drupal Commerce exposure.

Wiz researchers Yaara Shriki, Shahar Dorfman, Alma Blachsan and Yaron Samuel saw two clusters of activity:

• attempts that match the public proof-of-concept exploits
• “PHP2Shell-branded” tooling that does not exploit the PHP flaws at all, and instead chains session poisoning with a separate local file inclusion bug in the target application

The name on a tool says nothing about the bug it uses.

Wiz also found the public PoCs unreliable: “triggering memory exhaustion alone is not enough to complete the exploit chain,” because PHP builds, memory limits and worker behavior vary. Patch PHP anyway, since every Drupal store runs on it. But treat log scanning as log scanning: do not fold a PHP2Shell alert into a Commerce investigation unless the evidence links them.

What is still unknown about CVE-2026-118539?

Most of what a detection engineer needs is still unknown. Drupal has not published which routes or fields lack checks, whether exploitation requires an account, when it began, how many stores are affected or who is behind it. Without a CVSS vector, there is not even a stated attack complexity to reason from.

The patch is the fastest way to close part of that gap. Diff the fixed Commerce release against the one you run to see which access checks were added, then test those routes in staging as anonymous, customer and administrator users. Do not probe production stores for the exploit path. When Drupal or the credited researchers publish more detail, rerun your log review against it.

FAQ

What is CVE-2026-118539?

A missing-authorization flaw in the Drupal Commerce Core module. Certain routes and entity fields are not sufficiently protected, allowing an access bypass that may financially harm the store. Drupal rates it highly critical and says it is exploited in the wild.

Is CVE-2026-118539 a remote code execution bug?

Nothing published describes it as code execution. Drupal describes an access bypass on routes and entity fields with financial impact for the vendor.

Is Drupal Commerce Core 3.3.13 vulnerable or fixed?

The reporting lists 3.3.13 as both the upper bound of the affected range and the upgrade target, which is contradictory. Check the original advisory on drupal.org for the exact fixed release on your branch before marking a store patched.

Are there indicators of compromise for the Drupal Commerce exploitation?

No. Drupal published no IoCs, hashes, infrastructure, victim names or attribution. Detection depends on spotting unauthorized changes to orders, totals, accounts and permissions.

Do the PHP2Shell CVSS 9.2 scores apply to the Commerce Core flaw?

No. The 9.2 scores belong to CVE-2026-109618 and CVE-2026-109619 in PHP. CVE-2026-118539 has no published CVSS score, and no source links the two.

Does updating Drupal core fix CVE-2026-118539?

No. Commerce is a contributed project installed separately (drupal/commerce), so update it on its own, then run database updates and rebuild caches.

Once the patch is in, the open question is whether your store’s other routes and API fields enforce authorization the way you think they do. Our e-commerce penetration testing checks cart, checkout and Commerce API access by hand, role by role.