← All resources

Drupal Commerce flaw exploited: prices editable (28/10/2026)

Published November 2, 2026 · 7 min read · CyberNovaLabs.io

An access bypass in Commerce Core let a customer write the price and the state of their own order. Drupal scored it 21 out of 25, reported active exploitation and asked merchants to audit their orders. What an SME should check, and which regulatory clocks may start.

The short version

On 28 October 2026 the Drupal Security Team published advisory SA-CONTRIB-2026-254 and rated the Drupal Commerce flaw highly critical, 21 out of 25: an access bypass in Commerce Core, the module behind Drupal online shops^[1]. Tracked as CVE-2026-118539, it affects every version below 2.41 and versions 3.0.0 to 3.3.12, and the advisory states it is already being exploited^[1]. Drupal counted 42,002 sites reporting use of Commerce in the week of 18 October 2026^[3], and asks site owners to audit their orders for inconsistencies^[1].

What the Drupal Commerce flaw actually allows

Commerce Core checked permissions at entity level, not at field level. The module correctly enforced that you only touched your own cart — but not which fields of that cart you could write. An authenticated customer could therefore use the JSON:API and REST interfaces to write fields that were never theirs: total_price, unit_price, adjustments, state, uid and store_id on the order and its line items^[5].

Two more doors were open: the product_id field on a variation, which lets a variation point at another vendor's product, and the promotion_id field on a coupon, together with the order coupon management form^[5]. Drupal sums up the effect in one line: an access bypass that may financially impact the vendor^[1].

In commercial terms this is straightforward. An order can move to the paid state without a payment, or be paid at the price the buyer wrote. This is not a database theft: it is revenue lost line by line, with no security alert raised and nothing for an antivirus to catch.

Why "our Drupal is up to date" is not an answer

Commerce Core is not Drupal core: it is a contributed module. Core security releases and contributed module advisories follow two different calendars. A site whose core is perfectly current can stay vulnerable for weeks without anyone noticing.

On the same 28 October, Drupal published a second advisory on the same stack: Commerce License, rated moderately critical at 12 out of 25, CVE-2026-118555, fixed in 3.1.1^[2]. That one only affects sites that granted the permission to update one's own licence, but it can lead to an administrator role^[2]. If you sell subscriptions or licences, both advisories apply to you.

Timing matters more than severity here. The flaw is being exploited, so every day between 28 October and your upgrade is a window in which orders may have been rewritten by hand. It is the same pattern as the critical PHP flaws of October 2026: the useful question is not "am I vulnerable" but "what happened before I patched".

Two regulatory clocks, country by country

Order fraud does not automatically trigger a reporting duty. Two texts, two conditions, two recipients.

NIS2. For essential and important entities within the meaning of the directive, Article 23 provides for an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of that notification^[6]. The recipient is the national authority or CSIRT: the CCB in Belgium, NCSC-NL in the Netherlands, ANSSI in France, ILR in Luxembourg. Whether you are in scope depends on sector and size: our analyses walk through the test for Belgian webshops and marketplaces and for Dutch webshops and marketplaces.

GDPR. Article 33 requires notification to the data protection authority within 72 hours of becoming aware of a personal data breach^[7]: APD/GBA in Belgium, Autoriteit Persoonsgegevens in the Netherlands, the CNIL in France, the CNPD in Luxembourg. One useful distinction: an order paid at the wrong price is not in itself a personal data breach. The 72-hour clock only starts if customer data was read, altered or extracted — which only a log review can establish.

In both cases the starting point is awareness. That is why the written timeline — date of discovery, orders affected, amount, measures taken — is prepared before you call anyone.

Sizing your exposure in ten minutes

The figures below are working assumptions, to be replaced with your own.

Assume 40 orders a day, an average order value of 120 euros, a six-day window between the 28 October advisory and your fix, and 1% of orders manipulated. That gives 240 exposed orders and an order of magnitude of 288 euros. At 10% of orders manipulated, it becomes 2,880 euros. The point is not the result: it tells you how many orders you must review by hand, and therefore how much time to block out this week.

At CyberNovaLabs.io

We build and maintain shops and internal tools, and we keep the inventory of the components that run them: that register is what lets you answer "are we affected" in an hour rather than a week. If nobody can tell you today which Commerce Core version runs in production, that is the first job. See our custom software and application maintenance offer and our cybersecurity pages, or tell us about your shop in thirty minutes.

Sources

1. Drupal Security Team — Commerce Core - Highly critical - Access bypass - SA-CONTRIB-2026-254 (28/10/2026)
2. Drupal Security Team — Commerce License - Moderately critical - Access bypass - SA-CONTRIB-2026-260 (28/10/2026)
3. Drupal.org — Statistiques d'usage du module Commerce (semaine du 18/10/2026)
4. BleepingComputer — Drupal warns of critical Commerce Core flaw exploited in attacks (30/10/2026)
5. Ostorlab — Drupal Commerce Access Bypass, Exploited in the Wild (CVE-2026-118539) (30/10/2026)
6. Directive (UE) 2022/2555 (NIS2), article 23 — obligations de signalement
7. Règlement (UE) 2016/679 (RGPD), article 33 — notification d'une violation de données

Read next