Drupal says Commerce Core flaw CVE-2026-118539 is exploited; fixes are out, but the advisory gives no detail

Take one line away and Drupal's 21 out of 25 becomes 18

The Drupal Security Team rates SA-CONTRIB-2026-254, an access bypass in the Commerce Core module, Highly critical: 21 out of 25. The six values printed beside the score add up to 21 (derived: 4 plus 4 plus 3 plus 3 plus 4 plus 3). One of them, the exploit value, is worth 4 points because the advisory says exploitation is under way. At its lowest setting it is worth 1 point, and the total would be 18, which Drupal's own scale calls Critical, not Highly critical (derived). One sentence, "This vulnerability is being actively exploited in the wild.", therefore accounts for the whole gap between two bands, and it is the least documented sentence on the page.

What that does not establish is most of what a store owner needs. The advisory does not say who saw the attacks, when the first one happened, how many stores were touched, what the attackers changed, or what a changed order looks like. It names no route, no field and no entity, and prints no indicator. The fix is out on both branches the advisory names, so there is something to install today. But the only test of whether your own store was used is an audit that the advisory tells you to run and does not define. The advisory gives no CVSS score either: Drupal's score is its own, and no CVSS number exists in the CVE.org or NVD records at the time of reading.

This briefing reads the Drupal Security Team's advisory, the five advisories published with it, the release notes for Commerce Core 3.3.13 and 8.x-2.41, the CVE.org record, the NVD entry, the OSV record, CISA's catalogue file and drupal.org's usage page, between 09:49 and 10:03 UTC on Friday 30 October 2026. The Hacker News article that prompted it was read in a normal browser tab after scripted requests were refused; it repeats the advisory sentence, says Drupal gave no specifics about the activity or its extent, and names no other source. Two other reports, from SecurityOnline and Brandefense, were read: both repeat the advisory's own sentence and name no other source (secondary). Each is a commercial site that wants readers, and Brandefense also offers a domain risk score on the page. The advisory's authors are the Security Team's volunteers; the page lists 14 organisations as sponsors of time on the release (derived count). Their shared interest is a module that store owners keep trusting. Nothing here is a finding of compromise at any store.

Stated and not stated: what the advisory prints and what it leaves out

The advisory is short. It is one description paragraph, a two line solution and a list of credits. The table sets what it prints against what a store owner would need next. "Not stated" means not found in the advisory, the release notes or the CVE.org, NVD and OSV records read. It does not mean the information does not exist.

One word deserves a second look. The advisory says the bypass may financially impact "the vendor". In the CVE.org record, the vendor field says Drupal. In the advisory's sentence the module is described as one that sells goods and services, so the vendor reads as the store operator, the merchant, and not the software maker (inference). Reading it the other way would suggest the harm falls on Drupal, which nothing else on the page supports. The sentence says money is at risk and does not say whose till it is, or by what route.

Drupal's 21 out of 25 is not CVSS, and the exploit line is worth three points

Drupal's scoring page says its risk level "is based on the NIST Common Misuse Scoring System (NISTIR 7864)", scored from 0 to 25, with 20 to 25 called Highly Critical and 15 to 19 called Critical. It is not CVSS, and readers who see "Highly critical 21/25" in a feed should not read it as a CVSS 9 or 10. The page gives each metric value a point score. Applied to the vector printed on this advisory, AC:None is 4, A:None is 4, CI:Some is 3, II:Some is 3, E:Exploit is 4 and TD:All is 3, which is 21 (derived).

Zoom

The definition of the exploit value is stronger than the advisory's sentence. The scoring page says E:Exploit means "documented or deployed exploit code already in the wild", and E:Theoretical means no public exploit code or documentation exists. The advisory prints neither a document nor a deployed sample. So the number carries the claim of exploitation as if it were a measurement, while the record behind the claim is one sentence.

The same arithmetic was visible in an earlier briefing on a different Drupal flaw, the core Field UI advisory of 14 October: there, moving the exploit value from Theoretical to Exploit took a score of 19 to 22. That advisory carried no exploitation note when it was read. This one carries the note from its first published text, so far as the pages read show (the page prints no revision date).

The clock: fixed releases, an advisory an hour later, a CVE record 34 hours after that

All times are UTC and come from drupal.org release pages and feeds, the CVE.org record, the OSV record, the CISA file and the NVD entry. Every interval is derived from those stamps.

Zoom

Both fixed releases were created on 28 October, 3.3.13 at 15:42 and 8.x-2.41 at 15:53. The CVE.org record shows the identifier reserved at 15:50:46. The advisory carries the stamp 16:54:55, 1 hour 12 minutes after the first release was created (derived). The CVE record was published at 03:09:13 on 30 October, 34 hours 14 minutes after the advisory (derived), and the NVD entry at 04:18 the same morning, status Received, with no metrics. A process that waits for the CVE.org record or a CVSS score had neither for the first day and a half, and still has no score, while the advisory already said exploitation was under way.

Two things are not on the record. First, the release pages were edited again at 19:13 and 19:14 and the OSV record was modified at 20:08. None of those pages says what changed, so nothing read shows whether the exploitation sentence was in the 16:54 text. The OSV record's published stamp equals the advisory's, and its details text includes the sentence, but its modified stamp is later, so that is not proof (inference). Second, there was no early warning that the pages read show. The security announcements feed, read on the morning of 30 October, has no item after 21 October (a PHP update), although it does carry an advance notice for an earlier critical contributed project release on 23 September. For the core Field UI flaw in October, the team had published a notice two days before the release. Here, a store owner who watched that feed had none.

The CISA catalogue file, version 2026.10.29 released at 19:09 UTC on 29 October, lists 1,764 entries. None is Commerce Core and none is CVE-2026-118539. Its Drupal entries are for Drupal core, the latest added on 22 May 2026, and the entries with Commerce in the product name are for Adobe and SAP products, not this module. That describes one file at one time. A catalogue entry follows a listed exploitation, and absence from it is not a finding of safety. The file was read again at 10:02 UTC on 30 October and was the same version with the same result.

One update fixes six advisories, and one branch is not named

Both release pages list the same six advisories as fixed, and tell sites they are "urged to update immediately". The other five are not exploited on the advisories' own scores (Theoretical, or Proof for the last one), and each names a condition that this one does not.

The six advisories are 254, 255, 256, 257, 258 and 259. Their ranges differ slightly: 255 lists 3.0.0 up to but not including 3.2.0, and says 3.3.x is not affected, while its solution still sends anyone on 3.2.x or lower to 3.3.13.

Zoom

The usage page counts 42,002 sites for the week starting 18 October. The branch columns add to that total: 11,955 on 7.x-1.x, 13,028 on 8.x-2.x and 17,019 on the 3.x family (5 plus 673 plus 550 plus 1,252 plus 14,539, derived). So 30,047 sites, 71.5 per cent (derived), were on the two branches with a named fix. The week ended on Saturday 24 October, before the fixes existed, so no site could have been on 3.3.13 or 8.x-2.41. The page cannot say how many have updated since. It also counts only sites that report through Drupal's Update Status module, so it understates the real population by an unknown amount. Of the 13,028 sites on 8.x-2.x, 5,497 (42.2 per cent, derived) ran 8.x-2.40, the last release before the fix, dated 22 August 2024, 797 days before 8.x-2.41 (derived). Many of those stores have not taken an update for a long time, so the step to 2.41 may also be a step across years of changes.

Two compatibility facts sit on the release pages. 8.x-2.41 says it works with Drupal ^9.3 or ^10, and 3.3.13 says ^10.3 or ^11. A store whose Drupal core is older than 10.3 cannot take 3.3.13 as printed, so the fix may need a core update first (derived). Branch 7.x-1.x, with 11,955 reporting sites, is the gap. The advisory's range reads below 2.41, and its text sends anyone who uses "an earlier version" to 8.x-2.41, but the pages do not say whether 7.x-1.x is affected, is fixed or is unsupported. A store on it should ask its maintainers instead of assuming (inference).

Six labels that do the work of a control

A label is not a control. These six appear in this story, and each is comforting or alarming without telling a store owner what to do.

"Highly critical." A score on a Drupal scale that includes the exploitation claim as part of the number. It ranks urgency and tests nothing about your store.

"Being actively exploited." One sentence with no source, no date and no count. It is enough to justify moving today. It is not enough to say your store is or is not affected.

"The vendor." Probably the store operator, not the software maker (inference). Read the harm as yours.

"Audit your orders for inconsistencies." A store's order records are written by the same code that has the flaw, so an audit that only reads orders may read what the attacker left. An independent record, such as your payment provider's own ledger, is the better comparison (inference).

"I would have seen the notice." Advisory 258 says one forged request can dismiss the dashboard inbox for every administrator, including the notice that a security update is available. A dashboard that reports its own update can be silenced by the flaw class this release also fixes.

"A firewall will cover it." The advisory names no route and no field, so any rule written from outside is a guess (inference). No source read mentions a firewall rule or a Drupal Steward rule for this flaw, and the advisory gives no mitigation other than the update. A Drupal core update does not touch this: Commerce Core is a separate project from Drupal core, listed on the advisory with its own machine name, commerce.

Technical details

The primary sources print no route name, no field name, no request or response shape, no log line, no indicator and no commit link for this flaw, and no exploit. None is invented here. What they do print is below, copied as published, with the source and the date read. Describing the mechanism further would be guessing.

The first block is the risk line and the affected range exactly as the advisory prints them. A defender compares the range with the installed version of drupal/commerce, which is in the site's composer.lock file.

Project machine name: commerce
Date: 2026-October-28
Security risk: Highly critical 21 ∕ 25 AC:None/A:None/CI:Some/II:Some/E:Exploit/TD:All
Vulnerability: Access bypass
Affected versions: <2.41 || >=3.0.0 <3.3.13
CVE IDs: CVE-2026-118539

The next block is the whole of the advisory's description of the flaw and of the action it asks for. These are the only mechanism and action sentences the advisory contains.

The module doesn't sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.
This vulnerability is being actively exploited in the wild.
Sites should audit their orders for inconsistencies as this vulnerability is being actively exploited.

The CVE.org record adds a weakness class, CWE-862 Missing Authorization, and an attack pattern, CAPEC-87 Forceful Browsing. Its prose range says "to 2.41" and "to 3.3.13", while its structured version field says less than 2.41 and less than 3.3.13, matching the advisory. Treat the structured field and the advisory as the range, and the 2.41 and 3.3.13 releases as the fixed ones.

Missing Authorization vulnerability in Drupal Commerce Core allows Forceful Browsing. This issue affects Commerce Core versions: from 0.0.0 to 2.41, from 3.0.0 to 3.3.13.

The release pages print the Composer line for each branch and the SHA-256 of each tar.gz download. Composer is the install route Drupal's pages recommend, and the checksums let a team that downloads by hand confirm the file. The 3.3.13 page also links its tagged source tree, which answered when read; no page read names a fixed commit.

composer require 'drupal/commerce:^3.3'
3.3.13 tar.gz SHA-256: 6940f96d1226e594c3dc0ccf31cbbfd2288cb591a4f76907ab38c7a3a752b244

composer require 'drupal/commerce:^2.41'
8.x-2.41 tar.gz SHA-256: 7cf5bb824fe50c757cfa8ad86eed1dd247d4be560a11cb508f5e07e0027ffffb

One more line is this site's own, not the primary's. It is the standard Composer command that prints the installed version of a package, offered so that the inventory step in the checklist has a concrete first move.

composer show drupal/commerce

Against the earlier Drupal flaw: what is the same and what is not

The briefing on the core Field UI flaw asked a patch uptake question: 28.5 per cent of reporting sites then had no fix on their branch, a notice had come two days ahead, and no attack had been reported. This case flips three of those. A fix exists on both branches the advisory names, there was no advance notice that the pages read show, and the advisory says attacks are happening. It keeps two: the usage page's latest week ended before the fix, so there is no uptake figure yet, and one branch is left without a stated answer. The pattern across both is that the advisory is complete about what to install and silent about how to tell whether you were hit.

What to do, in order

The question that exposes the gap

For the last order your store completed before you updated, can you show, from a record the store itself does not write, that the amount the customer was charged matches the amount you were paid?

The advisory cannot answer it, the usage page cannot answer it, and a firewall cannot answer it. A payment provider's ledger can, and only if someone compares it with the orders before the logs rotate.

Key facts