Drupal Commerce Shops Hit by Live Attacks on Authorization Flaw
A missing permission check in Drupal Commerce Core lets strangers reach pages they shouldn't. Attackers are already trying it against live stores.
Key points
- Drupal is warning that criminals are actively attacking online shops running its Commerce Core module through CVE-2026-118539, a flaw published on 30 October 2026.
- The bug is a missing authorization check, meaning the software forgets to ask whether a visitor is allowed somewhere before showing certain pages.
- Affected versions run from 0.0.0 up to 2.41, and from 3.0.0 up to 3.3.13; shops on those builds need to update now.
- The attacks arrive while defenders are already stretched by active PHP exploitation we reported on 25 October, and Drupal runs on PHP.
- A live authorization bypass pointing straight at checkout is exactly the kind of opening extortion crews want.
Drupal has told site owners that hackers are actively exploiting a serious flaw in Commerce Core, the free add-on that turns a Drupal website into an online shop with a cart and checkout.
The flaw is tracked as CVE-2026-118539 and was published on 30 October 2026. Parts of the shop software forget to check whether a visitor is actually allowed to see or do something. Security people call this "forceful browsing": type in the right web address and the software hands over the page.
That's the whole trick. No stolen password, no clever code.
Which shops are affected?
Any Drupal site running Commerce Core from version 0.0.0 up to and including 2.41, or from 3.0.0 up to and including 3.3.13, is exposed. Treat the site as at risk until you've patched. The project describes Commerce Core as the module that lets a business sell goods and services with a built-in shopping cart, so the vulnerable software sits on the exact pages that handle customer orders and payments.
| Detail | Value |
|---|---|
| CVE | CVE-2026-118539 |
| Published | 30 October 2026 |
| Flaw type | Missing authorization (forceful browsing) |
| Affected (2.x) | 0.0.0 to 2.41 |
| Affected (3.x) | 3.0.0 to 3.3.13 |
| Exploited in the wild | Yes, per Drupal |
Move to a fixed release in the 2.x or 3.x line as published in the Drupal advisory, then check logs for odd requests to admin or order URLs.
How did the hackers get in?
They asked. That's the uncomfortable answer to a missing-authorization bug. Vulnerable code accepts a request for a protected page without checking the visitor's rights, so an attacker who knows or guesses the URL gets a response as if they were staff.
The Hacker News first flagged the active exploitation; Drupal has rated the issue "highly critical". A CVSS score hasn't been published on the CVE record yet, but the vendor's own severity tag is what matters for triage right now.
Should shoppers worry?
Not in a way they can act on directly. The weakness sits on the shop's servers, not on the buyer's phone or laptop. Nothing a customer clicks makes them more or less exposed.
Anyone who has bought from a small or mid-sized Drupal-powered store recently should watch card statements for unrecognised charges and treat any email about a recent order with suspicion, especially one asking to "reconfirm" payment details.
The wider picture
This lands in a bruising stretch for web defenders. As we reported on 25 October, two PHP flaws let attackers own web servers before the warning even went out. Drupal runs on PHP, so any shop that hasn't patched both the language underneath and the commerce module on top is carrying two publicly known holes at once.
Our e-commerce coverage has flagged this pattern twice in 90 days, starting with the Magento StyleSmuggler zero-day on 5 September. Checkout pages keep drawing fire.
My read: this is more urgent than the PHP pair for retailers, because it needs no exploit skill and lands straight at the transaction layer. Patch Commerce Core first, then PHP, then read your access logs. In that order.
