CVE-2026-118539: Drupal Commerce Core Access Bypass Exploited in the Wild
By ScruteXPublished
On 28 October 2026, Drupal shipped a fix for a flaw in Commerce Core and said, in the same advisory, that attackers were already using it. The flaw needs no login and no special configuration. It sits in the module that runs the cart, checkout and order APIs on Drupal stores.
CVE-2026-118539 is a missing authorisation flaw (CWE-862) in Drupal Commerce Core that lets anonymous users reach protected routes and entity fields. Attackers can read non-public data and change some of it, including order data. Drupal rates it Highly critical (21 of 25) and confirms exploitation in the wild. Commerce Core 3.3.13 and 8.x-2.41 fix it.
If you run a Drupal store, upgrade first and read the rest afterwards. If you are not sure whether you run one, the section on checking your exposure is for you.
Updates
| Date | Update |
|---|---|
| 28 Oct 2026 | Drupal publishes SA-CONTRIB-2026-254, releases Commerce Core 3.3.13 and 8.x-2.41, and confirms active exploitation. |
| 29 Oct 2026 | The CVE does not appear in the CISA Known Exploited Vulnerabilities catalogue, according to Ostorlab's review. |
| 30 Oct 2026 | NVD publishes CVE-2026-118539 with CWE-862. NVD has not yet assessed a base score. |
We will update this table as exploitation details emerge.
What is CVE-2026-118539?
CVE-2026-118539 is an access bypass in Commerce Core, the contributed module that turns a Drupal site into a store. Commerce Core provides the shopping cart, the checkout flow, order management and API access for headless storefronts and mobile apps. The module does not properly protect certain routes and entity fields, so requests that should be refused go through.
| Field | Detail |
|---|---|
| CVE | CVE-2026-118539 |
| Drupal advisory | SA-CONTRIB-2026-254, published 28 Oct 2026 |
| Drupal risk score | Highly critical, 21/25 (AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All) |
| CVSS | Not yet assessed by NVD |
| Weakness | CWE-862 Missing Authorization. NVD describes the attack pattern as forceful browsing |
| Affected | Commerce Core below 8.x-2.41, and 3.0.0 up to but not including 3.3.13 |
| Fixed | 3.3.13 (3.x) and 8.x-2.41 (earlier lines) |
| Exploitation | Confirmed in the wild by Drupal. An exploit exists |
| Reported by | Dan Puccetti, Marcus Johansson and Robert Snyder |
The missing CVSS score is a trap. Teams that triage on CVSS alone will see a blank field and push this down the queue. Drupal's own risk string says more than a CVSS number would: no access complexity, no authentication, all configurations affected, and a working exploit. Every input that makes a flaw urgent is already set to its worst value.
Is CVE-2026-118539 being exploited?
Yes. Drupal states in the advisory that the vulnerability "is being actively exploited in the wild", and its risk string marks the exploit status as "Exploit", the highest level. Drupal has not named any actor, shared the scale of the activity, or published indicators of compromise.
Two details shape the response:
- No public exploit code has been published. Ostorlab reported none as of 30 October. The exploitation Drupal confirmed came from someone with private tooling, either before disclosure or within hours of it.
- The fix diff is public. Commerce Core 3.3.13 shows exactly which routes and fields gained access checks. Patch diffs like this are how opportunistic attackers build their own tooling. Our assessment, at medium confidence, is that exploitation will widen from targeted to opportunistic scanning over the coming days.
There is also a quieter risk on the 2.x line. According to Ostorlab, the last 2.x release before this fix was 8.x-2.40 in August 2024. A store that has not needed a Commerce update in more than two years is easy to forget, and forgotten stores are the ones that get patched last.
How does the Drupal Commerce access bypass work?
Drupal checks permissions at two levels: whether a user may access an entity (an order, a coupon, a product) and whether they may read or change each field on it. When a site exposes entities through JSON:API or REST, both checks have to hold for every request. CVE-2026-118539 is a failure of those checks in Commerce.
Drupal's advisory gives only the summary. Ostorlab's review of the 3.3.13 diff fills in the detail. The fix adds access restrictions to:
- Order and order item fields, including
state,total_price,adjustments,unit_price,order_items,coupons,checkout_step,payment_gatewayandpayment_method. - Payment method fields, including the gateway, owner, remote ID and card fields.
- Product variation, coupon, promotion and store fields, such as a variation's
product_id, a coupon'spromotion_idand a store'sis_defaultflag. - Order admin routes, which now require the "access commerce administration pages" permission.
- The coupon autocomplete route, which listed coupon codes to any caller before the fix.
The functional tests that ship with the fix show the effect. Before the patch, a customer with update access to their own cart could change restricted order fields such as
state and total_price without any Commerce permission. A promotion owner could move coupons between promotions. JSON:API collection queries could reveal variations of unpublished products.These steps come from the fix's tests, not from observed attacks. They show what the flaw allows, not what any attacker has done.
MITRE ATT&CK mapping
| Technique | How it applies |
|---|---|
| T1190 Exploit Public-Facing Application | Anonymous requests reach unprotected Commerce routes and API endpoints on an internet-facing store |
| T1548 Abuse Elevation Control Mechanism | Missing authorisation checks let a visitor act with rights they were never granted |
| T1565.001 Stored Data Manipulation | Changing order totals, order state or coupon assignments alters records the business relies on |
T1548 is defined in ATT&CK around operating-system controls such as sudo and UAC, so it is a loose fit here. T1190 and T1565.001 describe the entry and the impact more precisely.
What can an attacker do with it?
The advisory says the flaw "may financially impact the vendor". In practical terms, the risk splits into three layers.
First-order impact: the store loses money. An order whose total or state was changed can look paid when the gateway never took the money. Leaked coupon codes turn into discount abuse. Unpublished product data, such as pricing for a launch, leaks early.
Second-order impact: customers become targets. Order records hold names, addresses, phone numbers and purchase history. A scammer who knows what a customer bought, when and for how much can make a fraud call that sounds exactly like the store. The customer pays for the store's failure, often without ever learning where the scammer got the details. Payment method records usually hold gateway tokens and card metadata rather than full card numbers, but exposure of those records still raises PCI DSS questions for the merchant.
Long-term impact: the clean-up costs more than the patch. Reconciling weeks of orders against gateway settlements, handling chargebacks, and deciding whether to notify a regulator take far more time than a module update. In India, CERT-In rules require reporting a cyber incident within 6 hours of noticing it, and the DPDP Act adds duties around personal data breaches. Other jurisdictions have their own clocks.
Who is exposed beyond retail. Drupal Commerce is not only for shops. Insurers, asset managers and banks use it to sell policies, collect fees, run reward catalogues and sell event tickets. These sites often sit on campaign subdomains, built and hosted by agencies. Indian stores carry one extra risk from the same release day: PayUmoney for Drupal Commerce is now unsupported, as the next sections explain.
Which versions are affected, and how do you fix CVE-2026-118539?
Every Commerce Core release below 3.3.13 on the 3.x line, and below 8.x-2.41 on older lines, is affected. Versions 3.3.13 and 8.x-2.41 are the fixed releases.
| Branch | Affected | Upgrade to |
|---|---|---|
| Commerce 3.x | 3.0.0 to below 3.3.13 | 3.3.13 |
| Commerce 8.x-2.x and earlier | below 8.x-2.41 | 8.x-2.41 |
The NVD entry words the ranges as "from 0.0.0 to 2.41" and "from 3.0.0 to 3.3.13". Read those with the semver bounds NVD also lists (0.0.0 < 2.41 and 3.0.0 < 3.3.13). The fixed releases are not vulnerable.
To upgrade a Composer-managed site on the 3.x line:
The Commerce 3.3.13 release notes list Drupal ^10.3 or ^11 as the supported core versions.
If you cannot patch today, reduce exposure until you can:
- Use your WAF to block anonymous POST, PATCH and DELETE requests to Commerce resources under JSON:API (
/jsonapi/commerce_*) and REST. - Restrict
/admin/commerceand order admin routes to trusted IP ranges. - If the store is low-value or seasonal, take it offline until it is patched.
These are stopgaps. They narrow the routes an attacker can reach, but they do not fix the field-level checks the patch adds.
What else did Drupal fix on 28 October?
Drupal released twelve more advisories in the Commerce family on the same day. Five more are in Commerce Core itself and close with the same upgrade. The rest need their own updates.
| Module | Advisory | Risk | Issue | Fix |
|---|---|---|---|---|
| Commerce Stripe | SA-CONTRIB-2026-263 | Critical 15/25 | CSRF: a crafted link clicked by an admin can let an order be marked paid with no payment | 2.2.3 |
| PayUmoney for Drupal Commerce | SA-CONTRIB-2026-277 | Critical 16/25 | Unsupported, known flaw unfixed | Uninstall |
| Commerce Core | SA-CONTRIB-2026-255 | Moderately critical 12/25 | Unpublished variations exposed through JSON:API | 3.3.13 / 8.x-2.41 |
| Commerce Core | SA-CONTRIB-2026-257 | Moderately critical 10/25 | Store owner can set their store as site default and receive others' orders | 3.3.13 / 8.x-2.41 |
| Commerce Core | SA-CONTRIB-2026-258 | Moderately critical 12/25 | CSRF in the Commerce dashboard inbox | 3.3.13 / 8.x-2.41 |
| Commerce Core | SA-CONTRIB-2026-259 | Moderately critical 11/25 | Repeated JSON:API queries reveal unpublished variation fields (proof of concept exists) | 3.3.13 / 8.x-2.41 |
| Commerce Stripe | SA-CONTRIB-2026-264 | Moderately critical 12/25 | Webhook signatures not verified when no signing secret is set | 2.2.3 or 8.x-1.4, and set a signing secret |
| Commerce Stripe | SA-CONTRIB-2026-265 | Moderately critical 11/25 | XSS in rare admin scenarios | 2.2.3 |
| Commerce Shipping | SA-CONTRIB-2026-261 | Moderately critical 11/25 | Carts with API access can change or delete shipments | 3.0.6 or 8.x-2.16 |
| Commerce License | SA-CONTRIB-2026-260 | Moderately critical 12/25 | License owners can raise their own rights, up to Administrator | 3.1.1, then review role licenses |
| Commerce Core | SA-CONTRIB-2026-256 | Less critical 9/25 | Promotion owners can change other promotions' coupons (needs JSON:API or REST writes) | 3.3.13 / 8.x-2.41 |
| Commerce Shipping | SA-CONTRIB-2026-262 | Less critical 8/25 | Resend receipt form exposes other customers' receipts | 3.0.6 or 8.x-2.16 |
Two of these matter as much as the headline flaw for a store's money. Commerce Stripe SA-263 is a second route to "paid without payment". PayUmoney is an Indian payment gateway, and Drupal now marks its Commerce integration unsupported with a known flaw left unfixed. The only safe action is to remove it and move to a supported gateway module.
Patch order: Commerce Core first, Commerce Stripe second, PayUmoney removal third, then Commerce License and Commerce Shipping.
Drupal runs on PHP, so check the servers too. PHP2Shell (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) gives unauthenticated code execution in PHP and is under active exploitation. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix it.
How to check whether your store was already hit
Drupal has published no IP addresses, hashes or request signatures. Hunt on behaviour, and go back as far as your logs allow, because the exploit existed before the fix.
In the order data:
- Reconcile order totals and payment states against your payment gateway's settlement records. Flag every order marked paid or completed with no matching transaction.
- Look for orders whose
total_price,adjustmentsorunit_pricechanged after checkout. - Check coupons whose
promotion_idno longer matches the promotion that issued them, and promotion deletions that removed other promotions' coupons. - Check product variations whose
product_idpoints to a product owned by a different account.
In the web and API logs:
- Anonymous or customer-account POST, PATCH and DELETE requests to Commerce JSON:API or REST resources. A 2xx response suggests success. After patching, 403 and 422 responses show attempts.
- Requests to the coupon autocomplete route that returned results.
- Bursts of requests from one IP address to order or product variation endpoints.
A starting point for Apache or Nginx combined-format logs:
If you find signs of misuse, preserve the logs before you rotate anything. Then reset affected orders, notify the payment provider, and start your reporting clock.
Why Drupal stores miss patches like this one
Drupal's security process is not the weak point here. The security team coordinated disclosure, published a clear risk score, credited the researchers and shipped fixes on the day of the advisory. The gap sits on the owner's side, in three places.
Contributed modules hide from inventories. An external scan can tell you a site runs Drupal 10. It usually cannot tell you which version of Commerce Core it runs. Asset registers list "the corporate website", not the module stack behind a campaign store.
Agencies run the stores nobody remembers. A reward catalogue for a credit card launch, a ticketing site for a conference, a merchandise shop for a sports sponsorship. These sites get built fast on a subdomain, handed to an agency for hosting, and dropped from the internal patch cycle.
Quiet branches go stale. A 2.x store that has needed no Commerce update since 2024 looks stable. It is also the store whose owner may not know who holds the Composer credentials.
Credentialed tools see module versions precisely. Drupal's Update Status module and
drush pm:security report contrib security updates on every site you can log in to, and you should run them today. Their limit is that they only cover sites you already know about. Finding the Drupal stores on your domains that nobody listed is a discovery problem, and it is the first stage of any continuous threat exposure management programme. Our external attack surface management guide covers how to run that discovery continuously.Key takeaways
- CVE-2026-118539 is an actively exploited access bypass in Drupal Commerce Core that needs no login. Drupal rates it 21 of 25.
- Upgrade to Commerce Core 3.3.13 or 8.x-2.41 now. The missing CVSS score is not a reason to wait.
- After patching, reconcile orders against gateway settlements. The flaw allows changes to order state and totals.
- Twelve more Commerce advisories shipped the same day. Commerce Stripe 2.2.3 and removing PayUmoney come next.
- The stores most likely to stay vulnerable are the ones outside your asset register: campaign, reward and agency-hosted sites.
Is CVE-2026-118539 reachable on your surface?
Check these five things. Each one is answerable from your own systems today.
- ☐ Do you run Drupal Commerce anywhere, including campaign stores, reward catalogues, ticketing sites, or a site an agency hosts for you?
- ☐ Is the installed Commerce Core below 3.3.13 on 3.x, or below 8.x-2.41 on 2.x? Run
composer show drupal/commerceordrush pm:securityon each site. - ☐ Is JSON:API or REST enabled, and do any Commerce resources accept anonymous writes?
- ☐ Do your October order totals and payment states reconcile with your gateway's settlement records?
- ☐ Is PayUmoney for Drupal Commerce still installed on any site?
What Scrutex finds here
Scrutex discovers the internet-facing sites on your domains, including the Drupal stores nobody registered, and identifies the technology each one exposes. The Exploit Context Layer then tells you whether there is a working exploit for that technology, whether it is being used in the wild, and whether the affected asset is reachable. For CVE-2026-118539, all three answers are already yes for any exposed store below 3.3.13, so the finding goes to the top of the queue. Where Scrutex cannot read the exact Commerce version from outside, it flags the site for a version check rather than guessing.
What that looks like
Illustrative finding format, redacted:
Is there a Drupal store on your domain you have not patched?
See which Drupal sites an attacker can reach on your domain. Free tier, no credit card, no agent. Findings start returning as soon as you add the domain.
Running Drupal on PHP? Check your sites for PHP2Shell with the free ScruteX PHP2Shell checker.
Scrutex sees only what is externally observable. If a store sits behind a VPN or on an internal network, we will not find it, and you will need your own inventory and
drush pm:security to cover it.If the exposed store is yours: Vulnerability Insights, which finds internet-facing assets outside your register and ranks them by real-world exploitability rather than raw CVSS.
If an agency or vendor runs it: Vendor Insights, which tracks the external posture of the third parties that host sites under your brand.
Go deeper: External attack surface management best practices, for running the discovery that finds stores like these before an attacker does.
Go sideways: Vendor security assessment template, for asking the agency that hosts your store how it patches contributed modules.
FAQ
Q: Is CVE-2026-118539 being actively exploited?
A: Yes. Drupal's advisory SA-CONTRIB-2026-254 states the flaw is being actively exploited in the wild and that an exploit exists. Drupal has not published attacker details or indicators of compromise.
Q: Which Drupal Commerce versions are affected by CVE-2026-118539?
A: Commerce Core 3.0.0 up to but not including 3.3.13, and all versions below 8.x-2.41. Commerce Core 3.3.13 and 8.x-2.41 are the fixed releases.
Q: Does CVE-2026-118539 have a CVSS score?
A: Not yet. NVD published the entry on 30 October 2026 without a base score. Drupal's own risk score is Highly critical, 21 out of 25, with no authentication or complexity required.
Q: What should I do if I cannot patch Drupal Commerce today?
A: Block anonymous POST, PATCH and DELETE requests to Commerce JSON:API and REST resources at your WAF, and restrict admin routes to trusted IP ranges. If the store is low-value, take it offline until you can upgrade. These steps reduce exposure but do not replace the patch.
Q: Do I need to update Drupal core as well?
A: The flaw is in the Commerce Core contributed module, not in Drupal core. Check the PHP version on the same servers, though: PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is under active exploitation and affects the PHP runtime Drupal depends on.