Hackers Exploit Critical Drupal Commerce Flaw

The flaw is tracked as CVE-2026-118539 and as Drupal advisory SA-CONTRIB-2026-254. Drupal describes it as an access bypass. In plain terms, the module does not sufficiently protect certain routes and entity fields, so someone can reach things they should not be able to reach. Drupal adds that the bypass "may financially impact the vendor". That is a careful sentence. It does not say every store will lose money, and it does not put a figure on losses. It says the risk is financial, not merely technical, which is why the order audit matters as much as the patch.

The news broke in three reports on 30 October 2026. The Hacker News reported Drupal's warning that threat actors are exploiting the flaw. SecurityWeek reported Drupal urging store owners to patch a highly critical access bypass exploited in the wild. BleepingComputer reported the same warning, with the same core advice: upgrade immediately and audit orders for inconsistencies. All three point back to the same Drupal advisory, published on 28 October 2026.

When was it discovered, and what do we actually know?

Here, precision matters more than speed. Drupal credited researchers Dan Puccetti, Marcus Johansson and Robert Snyder with reporting the flaw. The advisory itself does not give a discovery date, a first-exploitation date, or a description of the attack chain. SecurityWeek is explicit about those gaps: Drupal has not said how the bug is being exploited, who is behind the activity, or how many sites have been targeted, and it has not said whether exploitation began before patches were available — in other words, whether this was a zero-day in the strict sense.

"Actively exploited in the wild" is a confirmed status, not a rumour. It means Drupal has enough confidence to say attacks are happening, even though it is not sharing the operational details publicly. The National Vulnerability Database entry, published 29 October 2026, describes the weakness as missing authorization allowing "forceful browsing", under CWE-862 (Missing Authorization). Forceful browsing is a useful mental model: instead of breaking encryption or stealing a password, an attacker directly requests a route, page or field that the application was supposed to guard, and the application lets them through. No CVSS score had been assigned in NVD at the time of writing — NVD listed it as not yet assessed. Drupal's own risk score, 21 out of 25, is therefore the more useful severity signal for now. Secondary reporting of the risk string says unauthenticated attackers can exploit it regardless of configuration, with some impact on confidentiality and integrity. Treat the risk-string detail as reported, not as text from the short advisory page itself, but the headline is unambiguous: highly critical, unauthenticated, all configurations.

What is Drupal Commerce Core?

Commerce Core is not Drupal itself. It is a contributed module that turns a Drupal site into a store. Drupal's advisory puts it simply: the module enables you to sell goods and services through an included shopping cart and checkout form, or through decoupled applications via APIs. Drupal's statistics, cited by SecurityWeek and BleepingComputer, put Commerce Core usage at more than 42,000 sites, including, according to BleepingComputer, Fortune 500 companies and research universities. Read that number correctly. It is adoption, not a victim count. It does not mean 42,000 stores were attacked, and it does not mean 42,000 were vulnerable — some will already have been on fixed versions, some will not run the affected branches, and some will have additional protections. What the number does mean is scale: this is not a niche plugin. It is a widely used commerce framework, so a flaw in it deserves the same urgency as a flaw in a major payment or checkout component.

Commerce Core is also separate from Drupal core. Updating Drupal core alone does not update Commerce. That is a common and dangerous misunderstanding during a busy patch week, especially when Drupal published many advisories on the same day. The fix for this flaw is a Commerce Core release, not a Drupal core release.

Which versions are affected, and which are fixed?

The precise boundary, from NVD's version data, is:

Some news reports phrase the range loosely as "through 2.41" or "through 3.3.13". Do not read that as meaning the fixed releases themselves are vulnerable. The fixed releases are the boundary: if you are on 3.3.13 or 8.x-2.41, you have the fix for this advisory. If you are on any earlier release in those branches, you do not.

That matters for two reasons. First, a store that updated to 3.3.13 on 28 October and then read a headline saying "through 3.3.13" might wrongly conclude it is still vulnerable. Second, a store on an old 2.x release cannot simply "update Drupal" and assume it is safe; it needs the 8.x-2.41 Commerce release, or a planned move to the 3.x branch.

Drupal also published other Commerce advisories on 28 October, and the 3.3.13 and 8.x-2.41 release notes list six Commerce Core advisories in total, covering access bypass, information disclosure and cross-site request forgery issues, according to secondary reporting. Companion modules were also patched the same day. Those are separate advisories with their own fixed versions, and they should be checked as part of the same maintenance window — but they are not the same flaw as CVE-2026-118539, and a separate Commerce Stripe issue in that batch, where orders could be marked as paid without payment, should not be attributed to this CVE.

Which websites and businesses are at risk?

Any online store running a vulnerable Commerce Core version is at risk, regardless of size. The reported "all configurations" point removes the usual comfort that a particular setup might be safe. Size changes the blast radius, not the vulnerability.

The risk is also not limited to data theft in the abstract. Drupal says the bypass may financially impact the vendor, and it tells sites to audit orders for inconsistencies. That advice points to the most plausible business harm: orders, payments, discounts, fulfilment status or account-related fields being viewed or changed by someone who should not have access. Until a store has audited its orders, it cannot know whether the flaw was merely present or actually used against it. Patching closes the hole; it does not erase history. That is why the advisory pairs the update with an audit, and why later articles in this series cover the audit, the technical mechanism, and the recovery steps separately.

Customers are part of the risk picture too. A store holds accounts, order histories, addresses and payment-adjacent data, so an access bypass raises the possibility of exposure or alteration, even though Drupal has not confirmed a specific data-exposure pattern. Check first, then decide what customers need to be told under local rules. Do not claim a breach that has not been established, and do not claim "no impact" before the audit.

What is the official response so far?

Drupal's response, in the advisory, is three lines of action: upgrade to 3.3.13 or 8.x-2.41, and audit orders for inconsistencies, because the vulnerability is being actively exploited. The three news reports agree on that advice, and none of them adds a vendor statement beyond the advisory. There is, at the time of writing, no public statement from Drupal naming an attacker group, no published indicators of compromise, and no confirmed victim list. That absence is information, not an oversight to fill with speculation. It means defenders must rely on their own logs, order records and access records, rather than waiting for a public IOC list that may never arrive in a usable form.

The wider context also matters. SecurityWeek notes that Drupal published 38 other advisories on 28 October across 21 contributed projects, nearly a dozen rated critical, including issues that could lead to remote code execution, account takeover, or the separate Stripe order issue. Two weeks earlier, Drupal patched two critical remote code execution flaws in core components (CVE-2026-108097 and CVE-2026-108099), with no public reports of exploitation at the time of SecurityWeek's report. In May, Drupal warned about an exploited SQL injection flaw (CVE-2026-9082) that later entered CISA's Known Exploited Vulnerabilities catalogue. The pattern is not that Drupal is uniquely unsafe; it is that widely used open-source platforms are actively targeted, patches arrive in batches, and exploitation can follow quickly. The lesson for store owners is procedural: patching cannot be a quarterly task for a commerce site.

What should happen next?

For a store owner reading this today, the sequence is simple and urgent, and the detail is covered in the companion guides in this series:

1. Confirm whether you run Commerce Core at all, and which version. Many Drupal sites do not run commerce, and this flaw does not affect them.
2. If you run a vulnerable version, update to 3.3.13 or 8.x-2.41 in a tested way — backup first, update in staging if you can, then production, without delaying for a perfect window while exploitation is active.
3. Audit orders for inconsistencies: unexpected status changes, orders marked in ways that do not match payment records, unusual account or address changes, and any order activity that does not reconcile with your payment provider.
4. Check companion Commerce modules patched on the same day, and review logs for unusual access to commerce routes and fields.
5. If the audit finds inconsistencies, treat the store as potentially compromised, preserve evidence, and follow the recovery steps in the mitigation guide — patching alone is not proof that nothing happened before the patch.

For everyone else — developers, agencies and hosting providers — the next step is triage. Identify every client site running Commerce Core, sort them by version, and patch the vulnerable ones first. Do not assume a site is safe because it is small, behind a firewall, or "not a target". The advisory's unauthenticated, all-configurations framing, as reported, is precisely the kind of flaw that gets scanned for at scale.

This is a breaking-news report, so it will age. The facts that will not change are the advisory, the CVE, the fixed versions and the order-audit advice. The facts that may change are the exploitation picture: whether Drupal or a security firm publishes more detail, whether CISA adds this CVE to its catalogue, and whether individual stores report confirmed abuse. Watch the Drupal advisory page and the NVD entry for updates, and treat any new claim about victim counts or attack methods with the same scepticism this article applies to unconfirmed details: if it is not in the advisory or a credible primary source, it is not yet a fact.