Attackers actively exploit a critical authorization bypass in Drupal Commerce Core
On October 30, 2026, Drupal warned that CVE-2026-118539, an authorization flaw in the Commerce Core module, is being actively exploited in the wild. Any e-commerce site running Drupal Commerce must move to 3.3.13 or 8.x-2.41 without delay, then audit its orders and prices.
October 30, 2026. Drupal published security advisory SA-CONTRIB-2026-254 to warn that CVE-2026-118539 — an authorization flaw in the Commerce Core module — is being “actively exploited in the wild.” No CVSS score has been assigned yet. The point that matters: this is not a preventive patch, it is a patch under exploitation pressure, and it touches the merchant’s money, not just their data.
A commerce module with an authorization that does not hold
Commerce Core is the module that turns Drupal into a store: cart, checkout flow, payment handling, and an API for decoupled applications. The vulnerability is a missing authorization flaw. In practice, according to the advisory, “the module doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor.”
That wording is unusual and worth pausing on. Most Drupal advisories talk about data leakage or code execution. Here the vendor points directly at the merchant’s financial harm. That suggests the attacker is not merely reading: they can reach routes and fields that let them modify what a customer sees, orders, or pays for — typically prices, discounts, order states, or payment-related data.
The affected versions cover most of the installed base: the 3.x branch of Commerce Core up to and including 3.3.13, and earlier versions up to 8.x-2.41. In other words, any site that has not applied the patch published on October 30 is potentially exposed.
A simple fix with a wide blast radius
The fix is a routine minor update:
- 3.x branch — upgrade to Commerce Core 3.3.13.
- Earlier versions — upgrade to Commerce Core 8.x-2.41.
This is a routine upgrade, with no schema change and no heavy migration. But the simplicity of the fix must not mask the urgency: Drupal confirms active exploitation, which sets this flaw apart from one that was merely reported. Credit for the report goes to three researchers — Dan Puccetti (dpuccetti), Marcus Johansson (marcus_johansson), and Robert Snyder (rsnyd) — who reported it through the community’s responsible-disclosure channel.
Commerce Core is not an obscure plugin. It is the reference commerce building block of the Drupal ecosystem, used by retailers, B2B resellers, and public organizations that sell online. A flaw of this kind, exploited ahead of a widely deployed fix, has a blast radius far beyond a small business site.
What the advisory does not say yet
Drupal provided no details on the nature of the exploitation or the scale of the campaign. We do not know how many sites were affected, what vector the attacker uses, or whether this is an opportunistic actor sweeping the internet or a targeted operation against specific merchants. That restraint is consistent with the vendor’s practice of rarely publishing technical details before a patch has had time to propagate.
That lack of information has a direct operational consequence. With no public proof of concept yet, the only usable data is this: the exploitation is real, it targets a module that touches payments, and the window between the advisory and your site’s actual fix is the moment of maximum exposure.
The audit that follows the patch
Applying 3.3.13 or 8.x-2.41 closes the hole but does not undo what an attacker may already have done. The “financial” nature of the impact makes a post-patch audit necessary, the step too often skipped after a routine security fix. Three checks are worth doing within hours of the update:
- Orders and carts — look for modified orders, abnormal discounts, zero-priced line items, and suspicious state changes.
- Pricing and promotion rules — verify that pricing, discount, and tax rules have not been edited or disabled.
- Privileged accounts — look for newly created admin accounts or recent role escalations, since the authorization bypass is precisely the door into further access.
For an e-commerce site, these three checks are not a luxury: they are the difference between “flaw patched” and “flaw patched but already exploited.”
# Check the installed Commerce Core version with Drush
drush pm:list --filter=commerce --status=enabled
# Then upgrade to the fix via Composer
composer require "drupal/commerce:^3.3.13" --with-all-dependencies
drush updatedb
drush cache:rebuildVerdict
If you run a Drupal site with Commerce Core, apply 3.3.13 or 8.x-2.41 immediately: active exploitation leaves no room to defer a fix whose cost is a simple minor update, and the “financial impact on the vendor” makes the post-patch audit of orders and prices non-negotiable. If you operate a marketplace or a high-volume B2B reseller, treat this CVE as a security incident, not as maintenance: the value concentrated in orders and pricing rules makes your site a more profitable target than a retail storefront. And if you do not use Commerce Core, do not conclude too quickly: the lesson applies to any module that touches payments — an authorization flaw there has an immediate accounting cost where other flaws carry only a reputational one. CVE-2026-118539 is a reminder of a rule merchants forget: e-commerce security is not about data, it is about the till.