The Drupal Commerce vulnerability tracked as CVE-2026-118539 is being exploited against online stores. Drupal confirmed the attacks in an advisory on 28 October 2026 and fixed the flaw in Commerce Core 3.3.13 and 8.x-2.41. It rates the access bypass highly critical, 21 out of 25.
Which Drupal Commerce Versions Are Affected
The advisory covers two of the module’s three branches, and which one you are on decides what you install. Commerce Core is a contributed module rather than part of Drupal itself, so updating Drupal core does not patch it; check the installed Commerce package version.
| Your Commerce Core branch | Affected | Install this |
|---|---|---|
| 3.x, below 3.3.13 | Yes | Commerce Core 3.3.13 |
| 2.x, below 8.x-2.41 | Yes | Commerce Core 8.x-2.41 |
| 1.x, for Drupal 7 | Not covered by the advisory | No fix released |
Drupal’s published version range is anything below 2.41, plus 3.0.0 up to but not including 3.3.13. The 1.x branch for Drupal 7 sits outside the advisory entirely, which ITdaily reported on 30 October 2026 — Drupal has not said whether those sites carry the same defect, so roughly twelve thousand store owners cannot tell from the advisory whether they are exposed.
The same two releases also fix five lower-rated Commerce Core issues filed as SA-CONTRIB-2026-255 through SA-CONTRIB-2026-259. Only CVE-2026-118539 is described as under attack.
What the Access Bypass Lets an Attacker Do
An unauthenticated visitor can reach data and change records they should not be able to touch. Drupal’s advisory says the module “doesn’t sufficiently protect certain routes and entity fields”, producing an access bypass that “may financially impact the vendor”.
The 21-out-of-25 score breaks down into conditions that leave no safe configuration:
- Access complexity: none — the attacker only has to visit a page.
- Authentication: none — anonymous users can do it.
- Confidentiality: certain non-public data is released.
- Integrity: some data can be modified.
- Target distribution: all module configurations are exploitable.
Drupal has not said which routes or entity fields are involved. The security firm Ostorlab published its own analysis on 30 October 2026 arguing that Commerce checked access at the entity level but not at the field level, which it says allowed writes through JSON:API to order and order-item fields including state, total price and unit price, and allowed one vendor’s product variations and coupons to be reassigned. That reading is Ostorlab’s, derived from the tests shipped with the fix, not a Drupal statement.
How to Patch Commerce Core
The patch is a module update, not a configuration change, and it takes the usual Drupal release path.
- Check your version: confirm the installed Commerce Core release, not the Drupal core version.
- Update the module: install 3.3.13 if you are on 3.x, or 8.x-2.41 if you are on an earlier branch.
- Re-apply custom patches: any local patches against Commerce need reviewing against the new release.
- Rebuild caches: clear the Drupal cache so the corrected access checks take effect.
Drupal has issued no workaround and no mitigating configuration. Ostorlab notes that turning off JSON:API narrows the exposure but is not a substitute for the update.
Why the Patch Does Not Clear Your Past Orders
Installing 3.3.13 or 8.x-2.41 stops further abuse; it says nothing about what happened before you installed it. Because Drupal confirmed exploitation was already under way when it published the advisory, any store that patched on or after 28 October 2026 has a window in which records could have been altered.
That is why Drupal’s own instruction goes beyond upgrading: the advisory tells sites to “audit their orders for inconsistencies”. The flaw’s integrity impact is the point. An order that looks complete in the admin screen is not evidence that money arrived.
The pattern is a familiar one in exploited-before-patch disclosures. We reported the same gap when patching the Plex Media Server vulnerability did not clean an already-compromised server.
How to Audit Your Orders
The most specific guidance comes from Centarro, the company that maintains Drupal Commerce. Its founder Ryan Szrama — credited in Drupal’s advisory among those who fixed the flaw — published audit checks on 29 October 2026 written with the Drupal Security Team, as reported by The DropTimes.
- Match orders to access logs: compare order timestamps and IP addresses against your web server’s access logs to confirm each order actually moved through the checkout flow.
- Verify payment before fulfilment: per Centarro’s guidance, reaching the end of checkout does not confirm that payment was captured, so check the payment record before shipping.
- Look for price and total mismatches: compare order totals against the expected price of the items in them.
- Check coupons and promotions: look for redemptions attached to promotions they do not belong to.
- Check ownership: look for product variations or coupons that have moved between products or promotions.
An anomaly is not proof of compromise. A mismatch is a reason to check the order against the payment gateway’s own records, which sit outside the affected module.
How Many Stores Are Exposed
Drupal’s usage statistics put Commerce Core on more than 42,000 sites, a figure SecurityWeek and ITdaily both cite. ITdaily broke that down from the 18 October 2026 reporting week: 42,002 sites in total, of which 17,019 ran a 3.x release, 13,028 ran 2.x and 11,955 ran the Drupal 7 1.x line.
The two branches the advisory covers therefore account for roughly 30,000 sites. That is an exposure count, not a casualty count, and the distinction has been lost in some coverage: at least one aggregator headline framed the story as abuse across 42,000 sites. Drupal has not said how many stores were actually attacked, and nobody else has produced a number.
As of 2 November 2026, CVE-2026-118539 was still absent from the CISA Known Exploited Vulnerabilities catalog, which Rescana recorded against catalog version 2026.10.29 and Ostorlab confirmed in a check on 29 October 2026. A vulnerability under active attack without a KEV entry is not unusual; the same gap appeared with Atlassian’s CVE-2026-21589, exploited within hours and absent from the catalogue.
What Drupal Has Not Disclosed
The advisory is unusually bare for a flaw labelled as exploited. Four things are missing.
- Indicators of compromise: no request patterns, IP addresses or log signatures have been published.
- The affected routes and fields: Drupal describes them only in general terms.
- The evidence of exploitation: Drupal has not said what the finding rests on, or whether the flaw was used before a fix existed.
- Attribution and scale: no actor, campaign or victim count.
One consequence is already visible: the vulnerability tracker OffSeq lists the CVE as not known to be exploited, because no indicators were published for it to ingest, which directly contradicts Drupal’s own advisory. Store owners should treat Drupal’s advisory as the authority here, not automated feeds. Readers tracking content-management flaws with firmer regulatory deadlines can compare the handling of WordPress CVE-2026-87902 and its 28 September CISA deadline.
Drupal Commerce Vulnerability FAQ
Which Commerce Core Versions Fix CVE-2026-118539?
Commerce Core 3.3.13 fixes 3.x sites, and 8.x-2.41 fixes earlier releases. Both were published on 28 October 2026 and also address five lower-rated advisories.
Does Updating Drupal Core Fix This Flaw?
No. Commerce Core is a contributed module, so it updates separately from Drupal itself. Check the Commerce package version specifically.
Are Drupal 7 Commerce Sites Affected?
Drupal’s advisory does not cover the 1.x branch used on Drupal 7, and no fix was released for it. Drupal has not stated whether those sites share the defect.
Is CVE-2026-118539 in the CISA KEV Catalog?
Not as of 2 November 2026. Checks against catalog version 2026.10.29 found no entry, despite Drupal describing the flaw as actively exploited.
Can an Attacker Place Orders Without Paying?
Drupal says the bypass can modify some data and may financially harm the vendor, and Centarro’s guidance warns that a completed checkout does not prove payment was captured. Verify payment records before fulfilling orders placed before you patched.
