CVE-2026-118539

Why there is no CVSS score. Drupal scores each advisory on its own 0 to 25 scale, based on NIST's Common Misuse Scoring System. Scores of 20 to 25 are "Highly critical," the top band; 15 to 19 is "Critical." The 21 points break down as follows, using the definitions on Drupal's security risk levels page. AC:None (access complexity, 4 points), no special steps, the "user visits page." A:None (authentication, 4), no privilege needed, "all/anonymous users" can exploit it. CI:Some (confidentiality impact, 3), "Certain non-public data is released." II:Some (integrity impact, 3), "Some data can be modified." E:Exploit (4), "Exploit exists (documented or deployed exploit code already in the wild)," the highest value on that metric. TD:All (target distribution, 3), "All module configurations are exploitable," so no setting makes a site safe.

What's affected. The advisory's description is short. The module "doesn't sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor," and "Sites should audit their orders for inconsistencies as this vulnerability is being actively exploited." It does not name the routes or fields. The fix commits ("fix: Improve access control," October 28, 2f13d578 on the 3.x branch and 02d5bbe9 on 8.x-2.x at git.drupalcode.org) change the module's routing file, the cart query-access subscriber and the checkout controller, and add tests covering these areas.

• Customers editing restricted order and order item fields, including through JSON:API (for example, changing an order item's title).
• Changing the quantity or purchased item of a locked cart while the customer is on the payment step. The test notes say this could leave an off-site payment covering a stale total.
• Customers reaching admin order routes, or checking out draft orders that are not carts, through cart access.
• Payment method and customer remote ID fields being viewed or changed through JSON:API.
• Products taking over other products' variations, and coupons being moved between promotions, through JSON:API.
• Anonymous access to the customer and product variation autocomplete lists.

The commits do not say which of these is the one being exploited, so treat this as the scope of the fix, not a description of the attack. Credit goes to Dan Puccetti, Marcus Johansson and Robert Snyder for the report.

Checks, in order. Run these only on sites your organization owns.

1. Does the site run Commerce at all? If drupal/commerce is not in composer.json or composer.lock, this advisory does not apply.
2. Which version? Run composer show drupal/commerce. Anything below 8.x-2.41, or from 3.0.0 up to but not including 3.3.13, is affected.
3. Which submodules are on? Run drush pm:list --filter=commerce. The fix touches the cart, checkout, order, payment, product, promotion and store submodules. Because the rating is TD:All, don't treat a disabled submodule as protection.
4. Are cart and checkout reachable anonymously? On a working store they normally are, since anonymous shoppers need them. Assume they are unless the site is closed to the public.
5. Is JSON:API or REST enabled and writable? Many of the fix's tests use JSON:API. Check whether the jsonapi module is on and whether it is set to read-only.
6. Look for unusual activity since October 28. Run drush watchdog:show, and review web server logs for unusual requests to cart, checkout, order and JSON:API paths, such as order changes from anonymous sessions or repeated edits during payment.

Upgrading is the only fix the advisory gives. Use these to cover the gap and to find out whether you were hit, and test each one on the site where it matters.

• Upgrade first. 3.x sites go to 3.3.13; earlier versions go to 8.x-2.41.
• Audit orders. The advisory tells sites to "audit their orders for inconsistencies." Compare order totals, line items, unit prices and coupons against what was actually paid, starting from October 28 and working back.
• Restrict admin and API access. Limit /admin paths to trusted networks, and if you don't need writable JSON:API or REST, turn on JSON:API read-only mode or disable those modules until you've upgraded. Confirm the change by testing a write request from an anonymous session. The sources don't name specific routes to block, so no route-specific WAF rule is recommended here, and a generic rule is not a substitute for upgrading.

• Orders whose totals, line items, unit prices or coupons don't match what was paid, especially orders created or changed since October 28.
• Cart or order edits from anonymous sessions, and quantity or item changes on an order that was already at the payment step.
• JSON:API or REST write requests against order, order item, payment method, product variation or promotion entities from clients that shouldn't have them.
• Requests to admin order routes or autocomplete paths from anonymous sessions.

Is my Drupal site affected by CVE-2026-118539?

Only if it runs the Commerce Core module (drupal/commerce) below 8.x-2.41, or from 3.0.0 up to but not including 3.3.13. Sites without Commerce are not affected.

Is CVE-2026-118539 being exploited?

The Drupal Security Team says it "is being actively exploited in the wild." CISA has not added it to the KEV catalog as of October 29, 2026.

What is the CVSS score of CVE-2026-118539?

There isn't one. Drupal uses its own 25-point scale and rates it Highly critical, 21/25. NVD has not published a record.

Does updating Drupal core fix it?

No. This is in the Commerce Core contributed module. Upgrade Commerce to 3.3.13 or 8.x-2.41, then audit your orders.

Oct 29, 2026. First published. The Drupal Security Team reports active exploitation; not on CISA KEV; no NVD record.

• Drupal Security Team, SA-CONTRIB-2026-254
• Drupal security risk levels defined
• Commerce fix commit, 3.x branch and 8.x-2.x branch
• NIST NVD: CVE-2026-118539 (no record as of Oct 29)
• CISA Known Exploited Vulnerabilities catalog