What happened
On October 28, 2026, the Drupal Security Team published advisory SA-CONTRIB-2026-254 for the Commerce Core module. It is the core module of Drupal Commerce, which lets you sell goods and services through a built-in shopping cart and checkout, or through separate applications connected via APIs. The flaw is tracked as CVE-2026-118539 and listed in the European vulnerability database EUVD as EUVD-2026-113518.
According to Drupal, the module does not sufficiently protect certain routes and data fields, which allows access checks to be bypassed. Drupal warns that this may financially impact the shop operator. The flaw was reported by Dan Puccetti, Marcus Johansson and Robert Snyder.
Most importantly, Drupal states explicitly in its advisory that the flaw is being actively exploited in the wild. According to The Hacker News, Drupal has not shared details about the nature of the attacks or how widespread they are.
Why it is dangerous
This is a “missing authorization” flaw (CWE-862). For some functions, the application does not check whether the visitor is actually allowed to perform the action. Think of a storeroom whose door is tucked away down a back corridor but left unlocked: anyone who knows where to go can walk in. The official CVE description calls it “forceful browsing”, meaning direct access to addresses that should have been protected.
Drupal rated the flaw “Highly critical” with a score of 21 out of 25 on its own risk scale. That rating means the attack is not complex, the attacker does not need to log in, default configurations are affected and a working exploit exists. Drupal rates the impact on data confidentiality and integrity as partial. Because online shops are publicly reachable, an attacker can target them from anywhere on the internet.
Drupal has not described exactly what an attacker can obtain. It speaks of bypassing access checks on certain routes and data fields, with a possible financial impact on the shop. The advisory does not mention server takeover or code execution.
As of October 30, 2026, the flaw has no CVSS score yet, the international 0 to 10 severity rating. NVD has not assigned one either. There is also no EPSS value, which estimates the likelihood of exploitation in the next 30 days. The flaw is not yet in the CISA KEV catalog either, a list kept by the US agency CISA of vulnerabilities with confirmed exploitation. That does not matter here: Drupal itself has confirmed active exploitation.
Who is affected
This affects every Drupal site that uses the Commerce Core module (project commerce). That mainly means online shops built on Drupal Commerce and applications that talk to the shop through APIs. Vulnerable versions are:
- Commerce Core versions lower than 2.41
- Commerce Core versions from 3.0.0 lower than 3.3.13
These are typically online shops and ordering systems of companies and organizations, running on their own servers, on a VPS, or managed by a hosting provider or web agency. If an agency built your site, you may be using Commerce without knowing it.
Drupal sites that do not have the Commerce Core module installed are not affected. The flaw is in an add-on module, not in Drupal core itself.
How to check if you are affected
The easiest way is the Drupal admin interface. The Available updates page (/admin/reports/updates) shows the installed version of the Commerce module and flags any pending security update. You can also find the version in the module list at /admin/modules.
On the server, in the project directory, you can run these commands. They change nothing and only print the version or known security issues:
composer show drupal/commercedrush pm:list --type=module --status=enabled | grep -i commercedrush pm:securityIf you run a version from 3.0.0 lower than 3.3.13, or a version lower than 2.41, your site is vulnerable. Composer shows older versions without the “8.x-” prefix.
How to fix it
Drupal recommends installing the latest version:
- if you use version 3.x, upgrade to Commerce Core 3.3.13
- if you use an earlier version, upgrade to Commerce Core 8.x-2.41
Drupal does not list any workaround that could replace the update. Since the flaw is being actively exploited, update as soon as possible, ideally today.
Steps:
- Back up the database and site files.
- In the project directory, update the module with Composer (commands below).
- Run database updates and clear the cache.
- Check the version again and test the cart, checkout and payments.
- Audit your orders as Drupal recommends (see the next section).
composer update drupal/commerce --with-all-dependencies
drush updatedb
drush cache:rebuildIf a version constraint in composer.json blocks the new release, adjust it. If an agency or hosting provider manages your site, ask them to update today and confirm the installed version. Start with public shops that take real payments, then move on to staging and internal instances.
What if you may already be compromised
Drupal explicitly recommends that site operators audit their orders for inconsistencies, because the flaw is already being exploited. Drupal has not published specific indicators of compromise, such as attacker IP addresses.
What to look at:
- orders whose total, discount or line items do not match your price list
- orders marked as paid without a matching payment in your payment gateway
- order status changes that nobody on your team made
- unknown user accounts or unexpected changes to roles and permissions
- unusual requests in web server logs, especially repeated hits on shop and API routes from unfamiliar IP addresses
You can read Drupal’s own log with drush watchdog:show, or in the admin interface at /admin/reports/dblog if database logging is enabled.
If you find inconsistencies or suspect customer data has leaked, preserve the logs and bring in a security professional. If personal data was exposed, GDPR may require you to report the incident to your data protection authority within 72 hours.