Drupal has warned site administrators about a critical access bypass in Commerce Core, tracked as CVE-2026-118539. Attackers are already exploiting it (BleepingComputer). Commerce Core runs the shopping cart, checkout and commerce APIs on many Drupal stores, so a hole in its authorization can cost a store money directly. It is not only a data exposure risk.
This post covers what is known, what is still unclear, and how to respond.
What the flaw is
Drupal’s advisory, tagged highly critical, says the module “doesn’t sufficiently protect certain routes and entity fields, leading to an access bypass that may financially impact the vendor” (BleepingComputer). Key points:
- Weakness class: missing authorization (The Hacker News)
- Who can abuse it: unauthenticated attackers (BleepingComputer)
- CVSS: listed as N/A (The Hacker News)
- Reach: the module is used by more than 42,000 websites, including Fortune 500 companies and research universities (BleepingComputer)
The module serves both its built-in checkout form and decoupled applications through APIs (BleepingComputer). Headless storefronts are therefore in scope too.
Affected and fixed versions
| Branch | Reported affected range | Upgrade target named in reporting |
|---|---|---|
| 2.x (8.x-2.x) | 0.0.0 through 2.41 | 8.x-2.41 |
| 3.x | 3.0.0 through 3.3.13 | 3.3.13 |
Sources: BleepingComputer, The Hacker News.
Caution: the reporting conflicts with itself. The versions given as upgrade targets (3.3.13 and 8.x-2.41) are also listed as the top of the affected range. The likely meaning is that versions before those releases are affected, but neither source confirms this. Check the official Drupal advisory and the module’s release notes before you treat any version as safe.
Why it matters for e-commerce
The problem sits in routes and entity fields, and Drupal says the impact is financial. The main concern is the integrity of orders: prices, totals and order states could be changed in ways the store never meant to allow. Drupal’s advice to “audit orders for inconsistencies” points the same way (BleepingComputer). The sources do not say which routes or fields are involved, so a general audit is safer than looking for one specific pattern.
Response plan
- Inventory. Find every Drupal site running Commerce Core, including staging and headless backends.
- Patch. Upgrade to the fixed release for your branch, after confirming the version in the official advisory.
- Audit orders. Compare order totals against payment gateway records, and look for orders whose state or line items don’t match what checkout would produce.
- Review access logs. Look for unauthenticated requests to commerce and API routes, especially during the window before you patched.
- Reconcile and report. Escalate confirmed discrepancies to finance and payment providers.
Detection and hardening
The table below lists risk areas suggested by the advisory’s wording, alongside general defensive measures. The measures are standard practice, not steps Drupal has published.
| Risk area | What to check | Mitigation |
|---|---|---|
| Unprotected routes | Anonymous hits on commerce or API endpoints | Patch; restrict API exposure at the WAF or reverse proxy where possible |
| Entity field tampering | Orders with odd prices, totals or states | Reconcile against gateway records; alert on mismatches |
| Decoupled API clients | Unexpected API consumers or bursts of traffic | Rate-limit and authenticate API access |
| Patch lag | Sites still on old branches | Track module versions centrally |
Drupal’s busy 2026
This is not Drupal’s first critical issue this year (BleepingComputer):
- May: attackers exploited an SQL injection flaw in the database abstraction API (CVE-2026-9082). It could lead to privilege escalation, information disclosure and remote code execution. CISA added it to the KEV catalog and gave federal agencies three days to patch.
- About two weeks before this advisory: Drupal patched two remote code execution flaws (CVE-2026-108097 and CVE-2026-108099) and warned that exploits could appear “within hours or days.”
- Over the last several years, CISA has flagged five Drupal vulnerabilities as exploited in the wild. Ransomware gangs have abused two of them.
What to learn from this
- Read the official advisory before trusting a version number. Here the reporting lists the fixed versions inside the affected range.
- Patching doesn’t undo past abuse. Audit orders and payment records for the period before you patched.
- Include headless storefronts. The module serves decoupled apps through APIs, so API backends need the same patching and log review.
- Treat order integrity as a security signal. Routine reconciliation between orders and the payment gateway can catch authorization flaws that logs miss.
- Plan for fast exploitation of Drupal flaws. Several 2026 flaws were exploited or flagged as quick to weaponize, so give Drupal modules a short patch target.