Drupal's security team has published an advisory for Commerce Core, the contributed module that lets Drupal sites take orders and sell goods online. As reported by The Hacker News, Drupal rates the flaw "highly critical" and says it is being "actively exploited in the wild." The bug is tracked as CVE-2026-118539 and advisory SA-CONTRIB-2026-254. It is an access bypass: some parts of the store are not checked properly to confirm that the person asking for them is allowed to see or change them.
According to The Hacker News, the advisory gives no specifics about who is exploiting the flaw, how many sites are affected, or what the attacks look like. It does say the bug "may financially impact the vendor," meaning the store owner. Any Drupal site that takes money through Commerce Core should treat this as an emergency patch, not something to leave for the next maintenance window.
Below, we answer the questions administrators are most likely to ask.
What exactly is broken?
According to the advisory as quoted by The Hacker News, the module "doesn't sufficiently protect certain routes and entity fields, leading to an access bypass." Two Drupal terms need a quick explanation:
- Routes are the URL paths a Drupal site answers. They include the pages and API endpoints behind the cart, the checkout and other store functions.
- Entity fields are the individual pieces of data attached to Drupal objects. In a store, those objects include things like orders and products.
When routes and fields like these are not properly guarded, someone without the right permissions may be able to reach data or actions they should not have. The module works in two ways: it can provide a shopping cart and checkout form, or it can serve "decoupled applications via APIs," where a separate front end talks to Drupal. The advisory describes the module's purpose in both terms. The sources we read do not say which of the exposed routes or fields belong to which setup.
The CVE record files the bug under CWE-862, Missing Authorization. That category covers software that never checks whether a user is allowed to perform an action. The record also maps it to CAPEC-87, Forceful Browsing, an attack pattern where someone requests pages or resources directly instead of following the site's normal links and menus, because the server never confirms they have permission to view them. We are deliberately not describing which routes or fields are affected or how to reach them. Defenders don't need those details to fix the problem.
Which versions are affected, and what fixes it?
Both the NVD and CVE.org entries list the same affected ranges:
- Commerce Core from 0.0.0 up to, but not including, 2.41 (the 2.x line)
- Commerce Core 3.0.0 up to, but not including, 3.3.13
The fixed releases are Commerce Core 3.3.13 for sites on the 3.x branch and Commerce Core 8.x-2.41 for sites on the older branch, as reported by The Hacker News.
Is it really being exploited?
Drupal says so. According to The Hacker News, the advisory acknowledges the vulnerability is "actively exploited in the wild," but provides no detail on the activity, its scale, or who is behind it. None of our sources name a threat actor or a confirmed victim. Until Drupal or an affected merchant shares more, we can't say what attackers are doing with the flaw or how widespread the attacks are. We also aren't going to guess.
One data point points the other way, and it is worth knowing about. The CISA ADP entry attached to the CVE record, timestamped October 30, lists its exploitation field as "none," and marks the bug as automatable. That is a point-in-time assessment and it conflicts with Drupal's statement. We would not rely on it to delay patching, since the vendor is the party with the most direct view of its own advisory.
The CVE record shows the issue went public on October 28, 2026, and the CVE was formally published on October 30. It credits Dan Puccetti, Marcus Johansson and Robert Snyder with finding it.
Why does NVD say "medium" when Drupal says "highly critical"?
This is the part most likely to cause bad patching decisions. The NVD entry has the status Awaiting Analysis, which means NIST has not yet done its own scoring. The only score shown is a secondary CVSS 3.1 rating of 6.5 (Medium), with the vector AV:N/AC:L/PR:N/UI:N and low impact to confidentiality and integrity.
Translated, that vector says the flaw can be reached over the network, takes little skill, requires no login and needs no action from a victim. Those are the conditions that make a bug easy to exploit at scale. The medium overall score comes from the impact ratings, which assume an attacker gets only limited access to data or limited ability to change it.
Drupal uses its own risk-rating labels, and its advisory title calls this flaw "Highly critical." It also says attackers are already using it. A 6.5 in a vulnerability scanner does not cancel out an exploited, no-login bug in software that handles payments and orders. If your patch policy is driven by CVSS thresholds, override it for this one. The Hacker News listed the CVSS as N/A when it reported the story, which tells you how new the scoring data is.
What It Means for Defenders
Who is affected: Any Drupal site with the Commerce Core module installed at a version before 2.41, or from 3.0.0 up to but not including 3.3.13. That includes traditional storefronts with cart and checkout, and decoupled builds that use Commerce Core as an API backend. If you run Drupal and aren't sure whether Commerce is installed, check your enabled modules before assuming you're safe.
What to patch:
- On the 3.x branch, update to Commerce Core 3.3.13.
- On the older branch, update to Commerce Core 8.x-2.41.
- Patch production first if you have to choose, because that is where orders and payments are handled and the flaw is reported as exploited now. Update any internet-facing staging copies as well.
What to check after patching: None of our sources include indicators of compromise, so there's no specific signature to search for. Because the advisory warns of possible financial impact to the store owner, review recent order, pricing and payment records for anything you can't explain. Look for orders, totals or customer and order data that changed in ways that don't match normal admin activity. Check web server logs for unusual direct requests to store routes from clients who never went through the normal storefront. If you find anomalies, preserve the logs before you rotate or clean anything.
What to rotate: The sources don't say the flaw exposes credentials or secrets, so there's no specific rotation guidance. If your review turns up unauthorized access to admin or API functions, follow your normal incident process and rotate the API keys and integration credentials connected to the store.
For managed service providers and agencies: Commerce Core is a contributed module, so it may not show up in inventories that only track the version of Drupal core. Search every client site for the module directly.
For federal contractors working through CMMC: If a Drupal Commerce site is in scope for your environment, document the fix and when you applied it. The vendor's "highly critical, actively exploited" rating is the risk call to record. NVD's temporary medium score is not.
Watch for updates: NVD analysis is still pending, and Drupal may publish more detail about the exploitation. Keep an eye on the advisory, SA-CONTRIB-2026-254, which the CVE record references.
