Attackers are abusing Drupal Commerce Core. Patch now
Drupal says attackers are abusing a “highly critical” access bypass in Commerce Core. 42,000+ sites use it. Patches are out; order audits urged.
By Owen Reyes· Email Vox · 2 Nov 2026

Key facts
- ■Drupal confirmed active exploitation of CVE‑2026‑118539 in Commerce Core on Oct 28, urging immediate patches and order audits.
- ■Vulnerable versions include 3.x before 3.3.13 and 8.x‑2 before 2.41; admins should upgrade to those fixed releases.
- ■Commerce Core powers 42,000+ sites, raising risk of manipulated orders or payment states with real financial impact.
- ■Drupal shipped 38 additional advisories on Oct 28 across 21 projects; nearly a dozen are rated critical.
- ■Two core RCEs (CVE‑2026‑108097, CVE‑2026‑108099) were fixed on Oct 14; no public exploitation reports yet.
- ■A core SQL injection (CVE‑2026‑9082) targeting PostgreSQL saw exploitation attempts in May, showing active probing.
Timeline
- Oct 14, 2026Drupal fixed two critical RCE flaws (Field UI, Entity List)
- Oct 14, 2026Drupal warned Oct 14 issues could be exploited within hours or days
- Oct 28, 2026CVE‑2026‑118539 exploitation confirmed; 38 other advisories released
- May 2026CVE‑2026‑9082 SQL injection drew exploitation attempts
If your checkout runs on Drupal, today’s to‑do is short: patch, then comb through your orders. Drupal says attackers are already abusing a “highly critical” flaw in Commerce Core, the contributed module that powers shopping carts and checkouts for tens of thousands of sites.
Drupal tracks the bug as CVE‑2026‑118539 and rates it 21 out of 25 on its risk scale, meaning unauthenticated attackers can exploit it regardless of how the module is configured, according to SecurityWeek. The Drupal advisory says the module “doesn’t sufficiently protect certain routes and entity fields,” creating an access bypass with financial impact potential.
Versions matter here. Drupal lists 3.x releases before 3.3.13 and earlier 8.x‑2 series before 2.41 as vulnerable, and urges updating to one of those fixed versions. The Hacker News similarly flags versions 0.0.0–2.41 and 3.0.0–3.3.13, reinforcing the same upgrade targets.
Scope is big enough to hurt: Drupal’s own usage stats show Commerce Core runs on more than 42,000 sites. That’s a wide runway for checkout tampering, phantom payment states, or quietly altered order data if attackers can reach unguarded routes or fields.
Active abuse is confirmed, but details are thin. Drupal hasn’t disclosed how the exploit works, who’s behind it, how many stores were hit, or whether attackers had it before patches dropped. That ambiguity is common when fixes ship fast and defenders need time to investigate.
The immediate advice goes beyond patching: “Sites should audit their orders for inconsistencies as this vulnerability is being actively exploited,” the advisory says, per SecurityWeek. That points to reconciling order states against your payment processor, refunds, and captures to spot gaps.
There’s more housekeeping from the same batch. Drupal published 38 additional advisories on October 28, covering 21 contributed projects, with nearly a dozen rated critical, according to SecurityWeek. Issues include remote code execution (RCE), account takeover, and a Stripe integration bug that could mark Commerce orders “paid” without an actual payment.
Even the bot wall needed work: the CAPTCHA module picked up a fix for a moderately critical flaw that let a protected form be resubmitted without solving a new challenge. Drupal’s rating suggests exploit code exists, though the advisory didn’t confirm active abuse.
Information disclosure also got attention. Proofs of concept reportedly exist for leaks tied to Commerce Core and Media Alias Display, per Drupal’s ratings summarized by SecurityWeek. Data leakage paired with checkout manipulation is a recipe for targeted fraud.
This month wasn’t Drupal’s first scramble. On October 14, fixes arrived for two critical RCEs in Drupal core—CVE‑2026‑108097 in Field UI and CVE‑2026‑108099 in Entity List. Neither is exposed by core alone; certain contributed modules or custom code can make exploitation possible, sometimes without authentication, SecurityWeek reports.
Drupal warned on October 14 that exploits might surface within hours or days after those RCE patches. As of now, there are no public reports of in‑the‑wild exploitation for those two, but the Commerce Core bypass shows attackers are watching the ecosystem closely.
The platform has already been prodded this year. CVE‑2026‑9082, a highly critical SQL injection in Drupal core’s database abstraction API affecting PostgreSQL deployments, drew exploitation attempts in May, according to SecurityWeek. PostgreSQL‑backed sites were the specific target class for that one.
For the email world, the blast radius is practical: order confirmations and invoices may reflect tampered states if adversaries can flip fields behind the checkout. A fraudster who nudges “paid” to true without a charge can trigger downstream emails that mislead customers and support teams.
Even without direct mail compromise, compromised stores can push abnormal notification traffic or trigger disputes that dent sender reputation. We’ve seen how security shocks reverberate into inboxes in other corners of the stack—from the Cisco email gateway zero‑day to our explainer on why PHP2Shell went live before the patch mattered for web‑to‑mail touchpoints.
Patch speed matters because exploit speed keeps improving. When maintainers say attackers could move “within hours,” that’s not hypothetical; mass testing of fresh advisories is common, and defenders who wait for weekend maintenance windows often miss the safe window.
If you run Stripe, reconcile hard. Drupal’s Oct 28 batch explicitly mentions a bug that could mark Commerce orders as paid without actual payment in certain configurations. That’s where email receipts become misleading, disputes escalate, and chargebacks pile up quickly.
Don’t forget form workflows. The CAPTCHA resubmission issue implies attackers could replay certain form actions. If your password‑reset or support intake paths reuse components, audit for double‑submits that could trigger duplicate or unauthorized messages.
Logs tell this story best. Compare Commerce order tables to gateway events by ID and timestamp, and check for edits to entity fields tied to totals, taxes, discounts, or payment state. Any template changes to receipt or invoice emails during the exposure window deserve a second look.
After patching and reconciling, rotate sensitive keys that pass through the app: payment webhooks, tax/shipping APIs, and email provider tokens. That limits the fallout if the bypass exposed config pages or API endpoints.
If you need to message customers, keep it boring in a good way: send from your signed domain with SPF, DKIM, and DMARC aligned, and avoid sudden volume spikes that look like a breach. Our guide to harden deliverability when security headlines spike walks through pacing and proof.
Finally, treat this as a reminder that marketing stacks get hit, too. Adobe patched eight critical Campaign Classic bugs recently; we argued those weren’t optional updates for senders in our coverage of Adobe’s critical Campaign fixes. The common thread: web and email touch at checkout and comms—so patch both fast.
For ongoing coverage and practical steps across exploits and mitigations, check our Security hub.
The Email Vox take
-
If your store runs on Drupal Commerce, patch to 3.3.13 or 8.x‑2.41 today, then reconcile every order state against your payment gateway logs. Look for “paid” without a corresponding charge or capture.
-
Lock down what attackers could pivot to: rotate API keys (payment, tax, shipping, email), re‑sign Stripe webhooks, and review audit logs for template edits that could hijack receipts. If you must notify customers, keep deliverability intact by sending from a signed domain you control and avoiding sudden volume spikes—see our guide to harden deliverability when security headlines spike.
Frequently asked questions
- what is cve-2026-118539 in drupal commerce core?
- A highly critical access bypass in Drupal’s Commerce Core module that lets unauthenticated attackers reach protected routes and entity fields, risking financial impact to stores.
- which versions of commerce core are vulnerable?
- Drupal says 3.x before 3.3.13 and the 8.x-2 series before 2.41. The Hacker News notes 0.0.0–2.41 and 3.0.0–3.3.13.
- is the drupal commerce flaw being exploited now?
- Yes. Drupal confirmed active exploitation in the wild but hasn’t disclosed attacker details, targeted counts, or whether it was a zero‑day.
- how many sites run drupal commerce core?
- Drupal’s statistics show the module is installed on more than 42,000 sites.
- what should site admins do right away?
- Upgrade to 3.3.13 or 8.x‑2.41 and audit store orders for inconsistencies, per Drupal’s advisory.
- did drupal release other fixes this month?
- Yes. On Oct 28, 38 advisories for 21 contributed projects landed, with nearly a dozen critical issues. Two critical RCE bugs were fixed on Oct 14.
- could this bug affect order confirmation emails?
- If attackers altered orders or payment states, downstream emails (receipts, invoices) could be inaccurate or abused for fraud signals.
- were earlier drupal bugs exploited this year?
- Drupal says CVE‑2026‑9082, a core SQL injection affecting PostgreSQL sites, drew exploitation attempts in May.
Why this matters
E‑commerce modules often trigger a brand’s most trusted emails: order confirmations, invoices, shipping updates. If a checkout back end is quietly altered, those messages can misstate payment status or mask fraud. That hurts customer trust and can cascade into chargebacks, support load, and blocklist risk if compromised stores start sending abnormal traffic. Rapid patching and order reconciliation limit the blast radius. For senders, tight SPF, DKIM and DMARC won’t fix a hacked cart—but they keep incident notifications landable while you clean up, and help mailbox providers distinguish your messages from opportunistic phish.
Sources
Reporting draws on the public sources listed above. Spotted an error? Request a correction.
Follow-up coverage
Related coverage

Phish are now baiting your AI email assistant
Attackers are slipping hidden instructions into emails to steer AI assistants. Here’s how the trick works—and what to lock down before it bites.
15 Oct 2026

Germany’s DMARC push stalls: more reject, errors persist
A new review says 40% of Germany’s biggest domains now block spoofs at p=reject—but a third still fumble SPF or DMARC config.
19 Oct 2026

Fake invites, real theft: AitM phish steals Google MFA
Researchers say UAT‑11985 is phishing Taiwan research affiliates with fake invites and an AitM kit to grab Google logins and MFA codes.
17 Oct 2026

North Korea’s Kimsuky is email‑pitching Ukraine’s experts
A South Korean firm says Kimsuky used credible invites and research asks to pry into Ukraine’s war intel, then shifted to payloads hosted on developer platforms.
15 Oct 2026

Cyber insurers are now asking for DMARC receipts
Insurers now expect SPF, DKIM, and DMARC—while EU rules push the same controls. Here’s how underwriting shifted, what it asks in 2026, and why enforcement helps.
20 Oct 2026

Lock down your email in 30 days, no drama
A 30‑day security-and-deliverability tune‑up built from fall 2026 headlines: MFA‑bypass phish, AI‑baited inbox tools, Gmail’s vanished colors, and sharper blocklists.
18 Oct 2026