Drupal Says Commerce Core Is Being Exploited. The Advisory Names No Routes and No Indicators, So Here Is What You Can Check.
On October 28 the Drupal Security Team published advisory SA-CONTRIB-2026-254 for Commerce Core, the module behind a large share of Drupal online stores. It is rated highly critical, 21 out of 25 on Drupal's scale, it carries CVE-2026-118539, and it says plainly that the flaw is being exploited in the wild.
It is also a very short advisory. This post is what it says, what it leaves out, and what a store owner can check today.
What the advisory says
- Affected: Commerce Core below 2.41 on the 2.x line, and 3.0.0 up to but not including 3.3.13.
- Fixed in: 8.x-2.41 and 3.3.13.
- The flaw: certain routes and entity fields are not sufficiently protected, which allows an access bypass with possible financial impact on the store owner.
- Drupal's own scoring: no special conditions needed, some confidentiality and integrity impact, an exploit already existing, and every configuration of the module exploitable.
- The only instruction beyond upgrading: audit your orders for inconsistencies.
- Credit: the reporters are Dan Puccetti, Marcus Johansson and Robert Snyder.
What it leaves out
Nothing else. The page names no request paths, no routes, no field names, no addresses, no file hashes and no user agents. It does not say when exploitation began or how many stores were hit. It lists no workaround.
That matters because there is nothing to turn into a detection rule, and no indicator to put on a blocklist. We checked our own data to be sure:
- It is not in the catalog of exploited vulnerabilities that CISA publishes, as of our sync this afternoon. The newest additions there are from October 29.
- We hold no public proof of concept for it, and no indicators.
- It should not be confused with the Adobe Commerce and Magento bugs that landed in that catalog this month. Different product, different vendor.
So we are adding nothing to our feed for this one. An empty contribution is the honest one when the source gives us nothing to contribute.
What to check today
- Find your version. On a Composer-managed site, ask Composer which version of the Commerce package is installed. Otherwise read it from the status report in the admin area or from the lock file.
- Upgrade. Move 3.x sites to 3.3.13 and earlier sites to 8.x-2.41. The advisory lists no workaround, so patching is the control. If you cannot patch immediately, restricting access to the store while you do is our suggestion, not Drupal's.
- Audit orders, and go back further than feels necessary. The advisory does not say when exploitation started, so look back as far as your logs go. Compare your payment processor's settlement records with your own order records. Look for orders whose totals, prices, discounts or payment states do not match what the processor captured, completed orders whose fields changed afterward, orders that reached a paid state without a payment, and unexpected refunds or credits.
- Decide about customer data. The scoring includes some confidentiality impact. If your logs cannot rule out reads of customer or order data, treat that as a possibility and decide on notification with whoever advises you on it.
Limits
Everything here comes from the Drupal advisory and our own corpus. We did not reproduce the flaw, we have seen no exploitation ourselves, and the advisory gives us nothing that would let us look. News coverage in the first day repeated the advisory without adding detail, and a couple of outlets disagreed on the details, so we used only the advisory. If CISA adds it or a proof of concept appears, this post will be updated.
Five percent of this is wrong somewhere. It always is.
If this was useful, or was not, rate it at the bottom of the page.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.