News / Industry
Drupal Commerce access-bypass flaw exploited against online stores
Drupal warns an access-bypass flaw in Commerce Core, CVE-2026-118539, is being exploited to tamper with orders and prices on live online stores. Patch now.
The Drupal security team is warning that an access-bypass flaw in Drupal Commerce, the e-commerce layer behind tens of thousands of online stores, is already being exploited in the wild. Advisory SA-CONTRIB-2026-254, published on October 28, 2026, covers a missing-authorization bug in the Commerce Core module, tracked as CVE-2026-118539 and rated highly critical at 21 out of 25. The flaw needs no account and no password: an unauthenticated visitor can reach routes and entity fields the store is supposed to protect. Drupal is blunt about the stakes, saying the weakness can financially harm the store owner. When a payment-adjacent system can be reached by anyone with a browser, severity stops being theoretical.
| Key fact | Detail |
|---|---|
| CVE | CVE-2026-118539 |
| Product | Drupal Commerce Core module |
| Rating | Highly critical, 21/25 |
| Impact | Unauthenticated access bypass; order and price manipulation |
| Exploitation | Active in the wild |
| Fix | Upgrade to 3.3.13, or 8.x-2.41 on earlier branches |
What happened
Drupal published the advisory on October 28, 2026, and the matching CVE record followed on October 30. The problem is a missing-authorization flaw: the Commerce Core module does not sufficiently protect certain routes and entity fields, so the access checks that should gate them are never applied. Because those checks are missing rather than merely weak, an attacker does not need valid credentials to reach the exposed functionality. Drupal rates the issue highly critical at 21 out of 25 on its own scale; some third-party trackers describe it as critical on their own scales, but the project's rating is the authoritative one.
The exposure spans a wide band of releases. Drupal lists every version below 2.41 as affected, together with the 3.x line from 3.0.0 up to 3.3.13. The fix is to upgrade to 3.3.13 on the 3.x branch, or to 8.x-2.41 on the earlier branch. There is no partial mitigation that substitutes for the update, so store owners on an affected release should treat the upgrade as urgent (SecurityWeek).
Because the bug is being exploited now, patching is only half the job. Drupal advises store owners to audit recent orders for inconsistencies, and it names the specific signals to look for: unexpected prices, totals, or status changes that do not match what the store intended. An order that was quietly rewritten before the patch will not correct itself. Drupal Commerce runs on more than 42,000 sites by the project's own module statistics, which sets the outer bound on how many merchants now have that review in front of them. Alongside this flaw, Drupal published additional related Commerce advisories in the same window, though the specifics of those are best confirmed directly against the project's security feed.
Why it matters
An online store is one of the few applications where a software flaw maps directly to money. The system that prices a cart, applies a discount, and records an order is the same system an attacker wants to influence, and Drupal's warning about financial harm is a plain description of what order and price manipulation means for a merchant. That puts this flaw in a different category from a defacement or a simple information leak.
Two factors compress the timeline. The first is that the bug is unauthenticated, which removes the usual barrier of needing a stolen account or an insider; the reachable attack surface is anyone who can load the site. The second is that it is already being exploited, so the quiet period in which defenders normally plan a maintenance window has closed. This follows a familiar pattern across the web stack, where critical flaws in widely deployed components draw exploitation quickly once the details are public.
Drupal has also been under sustained pressure. About two weeks before this advisory, the project patched two critical remote-code-execution bugs in Drupal core and the Field UI module, CVE-2026-108097 and CVE-2026-108099, and warned that working exploits could arrive within hours or days of the fix. This Commerce flaw lands on sites that were still absorbing that round, a reminder that patching a Drupal store is a recurring duty rather than a one-time event.
It is also a clean case for exploitation-led patching. A store may be carrying dozens of open advisories across its modules and server software, but a flaw that is both reachable without credentials and confirmed in active use belongs at the top of the queue. That is the core of prioritizing by what is reachable and exploited rather than by a severity label alone.
The chart traces the same four steps the advisory describes. An unauthenticated visitor arrives with no credentials, reaches an unprotected route that should have been gated, slips past the access control that was never applied, and ends by tampering with an order's price, total, or status. Each step is ordinary on its own. The failure is that nothing in the chain stops the first step from reaching the last.
An unauthenticated flaw in the code that prices and records a sale is not just a web bug. It is a direct line to revenue, open to anyone with a browser until the update lands.
The attack-surface read
The merchants most exposed here are the ones that cannot quickly say whether they run Drupal Commerce, on which version, and whether it faces the internet. AI-native exposure management is built to keep that answer current, matching the internet-facing applications and plugins you run against the flaws now under active attack, so an advisory like this becomes a short list of named systems rather than a scramble; it is also why the gap between your attack surface and the paths through it is worth understanding before an incident forces the lesson. If you sell online, confirm your Commerce version today and upgrade any instance below 3.3.13 or 8.x-2.41.