A Drupal Commerce vulnerability rated Highly critical is being exploited on live stores, according to Drupal’s security team. The advisory, SA-CONTRIB-2026-254, came out on October 28, 2026, with fixed releases of Commerce Core: 3.3.13 and 8.x-2.41.
This Drupal Commerce vulnerability matters to our readers. Associations and nonprofits use Drupal Commerce for membership dues, event registration, donations and store sales. This post covers what the advisory says, what the maintainers say attackers did, which versions to install, and how to audit your orders. It also covers the other Commerce advisories released the same day, because most stores run several of those modules together.
The short version: update Commerce Core today, along with Commerce API, Commerce License, Commerce Shipping and Commerce Stripe if you use them. Then check recent orders for ones marked paid with no matching payment, ones placed without payment, and prices or discounts nobody on staff set. Do not ship goods or confirm registrations until payment is confirmed.
What Drupal’s advisory says about the Drupal Commerce vulnerability
The SA-CONTRIB-2026-254 advisory says Commerce Core "doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass." It adds that the flaw may financially affect the vendor. The CVE is CVE-2026-118539.
Two lines stand out. The advisory says "This vulnerability is being actively exploited in the wild." It also says "Sites should audit their orders for inconsistencies as this vulnerability is being actively exploited."
The risk score is 21 out of 25, which falls in Drupal’s Highly critical band of 20 to 25. Drupal’s risk level definitions explain the parts of the score:
| Metric | Value | What it means |
|---|---|---|
| Access complexity | None | No special setup needed to attack |
| Authentication | None | No login needed |
| Confidentiality and integrity impact | Some, Some | Some private data exposed, some data can be changed |
| Exploit | Exploit | Working exploit code exists or is in use |
| Target distribution | All | All module configurations are exploitable |
In plain terms, an anonymous visitor can abuse this Drupal Commerce vulnerability, it works on default setups, and it is already in use.
Which Commerce Core versions are affected
According to the advisory, every Commerce Core release below 2.41 is affected, and so is every 3.x release from 3.0.0 up to 3.3.13. The fixes are:
- Commerce 3.x: install 3.3.13.
- Commerce 2.x: install 8.x-2.41.
Both releases came out on October 28, according to the Commerce Core project page. The page reports 42,002 sites using the module. It also lists the Drupal versions each branch supports. Commerce 3.x runs on Drupal 10.3 and later or Drupal 11. Commerce 2.x runs on Drupal 9.3 and later or Drupal 10.
The 3.3.13 release notes say the release fixes security vulnerabilities and urge sites to update immediately. They link six Commerce Core advisories, not one. More on those below.
What attackers did with this Drupal Commerce vulnerability
The advisory does not describe the attack. Centarro, the company that maintains Drupal Commerce, did. Its October 29 post by Ryan Szrama was written with the Drupal Security Team.
According to Centarro, merchants reported attempts to place fraudulent orders on live sites. Centarro lists four ways the checkout could be manipulated, from simplest to most involved:
- Placing an order without completing payment.
- Marking an order as fully paid in the back office with no payment behind it. Centarro says this mainly affects sites that allow updates through JSON:API.
- Changing prices, so orders carry prices nobody set. Centarro says reported orders included prices of $0.01 next to normal ones.
- Adding discounts, fees or other adjustments that no staff member or promotion created.
Centarro says the Drupal Commerce vulnerability affects both standard and headless sites, though the path differs. It also says: "As of now we do not believe it was scripted or exploited beyond the initial sites." That is the maintainer’s view as of October 29. Do not treat it as a reason to wait.
How far back does exposure go? Centarro says exploits have been possible since Commerce Core 8.x-2.18 (released May 26, 2020) on JSON:API sites. For other sites, it dates exposure to 8.x-2.25 (released June 30, 2021). That means an audit may need to cover more than the last few weeks.
How to audit orders after the Drupal Commerce vulnerability
The advisory tells sites to audit orders. Centarro’s post gives the specific checks. Here they are in plain terms, for the person who runs your store day to day:
- Placed but unpaid. Look for recent orders that were placed but have no completed, pending or authorized payment. If your site does not offer free orders, any free order is worth a look.
- Paid with no payment. Look for orders marked paid that have no payment records attached.
- Odd prices. Look for prices that do not match your catalog. Centarro points to the "Override the unit price" setting on order items. On most sites, staff rarely use it.
- Unknown adjustments. Open the order summary and look for discounts, fees or other lines nobody on staff added.
Centarro also gives four database queries for developers. They look for orders that never reached the checkout’s final step, orders where the total paid is higher than the payments recorded, order items with an overridden price, and adjustments added by hand. Each query will also catch some legitimate orders, such as staff-entered orders, donation products where buyers set the amount, and manual discounts. Someone who knows your store has to review the results.
Centarro suggests one more step. Match the IP addresses and times of suspicious orders against your web server’s access logs for checkout paths. That shows whether an order went through the normal checkout or around it.
If you find bad orders, follow your incident steps. Our data breach response plan guide covers who to tell and what to record.
Change how you fulfill orders
Centarro’s post includes two changes that apply beyond this one Drupal Commerce vulnerability.
First, it says the details of an order, including full payment, should be confirmed before any goods or services are delivered. For an association, that means checking payment before a registration badge prints or a member benefit unlocks. Many sites automate that step on order placement. This exploit shows why that is risky.
Second, if your site does not need to update data through JSON:API, Centarro recommends switching it back to read-only. Many sites turn on write access for a decoupled front end or an integration and never turn it off. Our explainer on headless CMS setups covers why a site might expose an API like this.
The other Commerce advisories from October 28
Drupal published 39 contrib advisories on October 28, according to its contributed project advisories list. Thirteen involve Commerce modules. Centarro asks stores to update Commerce API, Commerce License, Commerce Shipping and Commerce Stripe at the same time as Commerce Core. Commerce API does not appear in the list for October 28, so check its project page for the release.
| Module | Advisories | Highest rating |
|---|---|---|
| Commerce Core | SA-CONTRIB-2026-254 to 259 (access bypass, information disclosure, cross-site request forgery) | Highly critical |
| Commerce Stripe | SA-CONTRIB-2026-263 to 265 (cross-site request forgery, signature check, cross-site scripting) | Critical |
| Commerce Shipping | SA-CONTRIB-2026-261 and 262 (access bypass) | Moderately critical |
| Commerce License | SA-CONTRIB-2026-260 (access bypass) | Moderately critical |
| PayUmoney for Drupal Commerce | SA-CONTRIB-2026-277 (unsupported) | Critical |
The Commerce Stripe advisory deserves its own look if Stripe takes your payments. One of its three advisories is rated Critical. If you use PayUmoney for Drupal Commerce, the module is now marked unsupported, so plan to remove or replace it.
The rest of the day’s list covers modules such as the AI module, Single Content Sync and Field Permissions. Our October 21 contrib advisories post shows how we sort a long list like this by risk.
What this means for Drupal 10 and Commerce 2.x stores
Commerce 2.x stores are the ones most likely to be on Drupal 10. Centarro’s post says "support for 8.x-2.x will sunset when Drupal 12 is released." Drupal’s core release schedule puts Drupal 12 in the week of December 7, 2026. Centarro recommends moving to Commerce 3.x as soon as you can.
Drupal 10 reaches end of life on December 9, 2026. After that date, Drupal 10 sites get no more security fixes. Commerce stores still on Drupal 10 and Commerce 2.x face two deadlines at once. See our Drupal 10 end-of-life guide and our plain-language guide to the Webform advisories for what to check now.
For the upgrade itself, our Drupal 10 to 11 migration guide walks through the steps. For a store, plan extra testing time for checkout, payment gateways and tax.
What to do this week
- Update Commerce Core to 3.3.13 or 8.x-2.41 to close the Drupal Commerce vulnerability. With Composer, update the
drupal/commercepackage and run database updates. - Update the related modules you use: Commerce API, License, Shipping and Stripe.
- Audit orders using the four checks above, going back as far as your records allow.
- Pause automatic fulfillment until payment is confirmed.
- Set JSON:API to read-only if nothing needs to write through it.
- Plan the Drupal 10 move if your store is still on Drupal 10.
If you also manage WordPress sites, today’s WordPress 7.1.4 security release post covers a separate set of fixes due this week.
Frequently Asked Questions
What is the Drupal Commerce vulnerability in SA-CONTRIB-2026-254?
It is an access bypass in Commerce Core. Drupal’s advisory says certain routes and entity fields were not protected well enough. It is rated Highly critical, 21 out of 25, and is being exploited.
Which versions fix the Drupal Commerce vulnerability?
Commerce Core 3.3.13 for the 3.x branch and 8.x-2.41 for the 2.x branch. Both were released on October 28, 2026.
Do attackers need an account?
No. The advisory’s risk score marks authentication as None, which means no login is needed. It also marks all module configurations as exploitable.
What did attackers actually do?
Centarro, the Commerce maintainer, says merchants saw fraudulent orders. These included orders placed without payment, orders marked paid with no payment, altered prices including $0.01 items, and adjustments nobody on staff added.
How far back should we audit orders?
Centarro says exploits were possible since 8.x-2.18 (May 2020) on JSON:API sites and since 8.x-2.25 (June 2021) on others. Audit as far back as is practical, starting with the most recent orders.
Does this affect headless or decoupled stores?
Yes. Centarro says both full-stack and headless sites are affected, though the attack path differs. Sites that allow updates through JSON:API had an extra route.
We use Stripe. Is there anything extra to do?
Yes. Commerce Stripe had three advisories on October 28, one rated Critical. Update it along with Commerce Core.
Is Commerce 2.x still supported?
For now. Centarro says support for 8.x-2.x will end when Drupal 12 is released, which Drupal schedules for the week of December 7, 2026. Plan a move to Commerce 3.x.
What if we find fraudulent orders?
Do not fulfill them. Record what you found, cancel or refund as your policy allows, and report suspicious behavior through Drupal’s security process. Check your access logs to see how the orders were placed.
