What happened

• Drupal warned administrators that CVE-2026-118539, a missing-authorization access bypass in the Commerce Core module, is being actively exploited [S1][S2].
• Reported affected versions are Commerce Core 0.0.0 through 2.41 and 3.0.0 through 3.3.13. Reported fixes are 3.3.13 and 8.x-2.41 [S1][S2].
• The Drupal security team advises auditing orders for inconsistencies after upgrading [S1].
• The sources publish no exploitation artifacts, log patterns or indicators [S1][S2].

Timeline

Detect

Write requests to Commerce order endpoints from outside admin sessions · Web server / reverse proxy / WAF access logs for Drupal sites

index=* (uri_path="*/jsonapi/commerce_order*" OR uri_path="*/admin/commerce/orders*" OR uri_path="*/commerce_order*") http_method IN ("POST","PATCH","PUT","DELETE") status<400 | stats count min(_time) as first max(_time) as last values(uri_path) as paths values(http_user_agent) as ua by src_ip, http_method | sort - count

FROM logs-* | WHERE (url.path LIKE "*/jsonapi/commerce_order*" OR url.path LIKE "*/admin/commerce/orders*" OR url.path LIKE "*/commerce_order*") AND http.request.method IN ("POST","PATCH","PUT","DELETE") AND http.response.status_code < 400 | STATS count = COUNT(*), first = MIN(@timestamp), last = MAX(@timestamp), paths = VALUES(url.path), ua = VALUES(user_agent.original) BY source.ip, http.request.method | SORT count DESC

A hit means: A client changed order data through a Commerce route. This is generic: the sources publish no exploit pattern. Check whether the source IP and session belong to a known administrator or integration. If they do not, treat it as a candidate exploitation attempt and compare against order audit results.

Unauthenticated successful access to Commerce admin or order routes · Web server / reverse proxy access logs for Drupal sites

index=* (uri_path="/admin/commerce*" OR uri_path="*/commerce_order*" OR uri_path="/user/*/orders*") status=200 NOT http_cookie="*SESS*" | stats count values(uri_path) as paths values(http_method) as methods by src_ip | sort - count

A hit means: Order or admin Commerce pages returned 200 to a request without a Drupal session cookie. That is consistent with an access bypass, but cookie logging varies by site. Confirm with application logs before acting.

Verify

• Match each hit to the Drupal watchdog and dblog entries and the order revision history for the same time window. Look for changes made by anonymous users (uid 0) or unexpected accounts.
• Compare the affected orders' totals, line items, status and customer fields against payment processor records. Drupal advises auditing for inconsistencies [S1].
• Benign look-alikes: payment gateway callbacks and webhooks, ERP or fulfilment integrations using API keys, headless storefronts using JSON:API, and admin sessions where cookies are not logged.

Scope

Affected

• Drupal Commerce Core 0.0.0 through 2.41
• Drupal Commerce Core 3.0.0 through 3.3.13

Only if

• Commerce Core module installed
• Unauthenticated access to affected routes and entity fields

Not affected if

None stated by the sources.

Fixed in: Commerce Core 3.3.13 or 8.x-2.41 (as reported; the ranges overlap the fixed versions, so confirm against the Drupal advisory)

Enumerate

• All Drupal sites, including marketing, vendor-hosted and agency-run ones, that have Commerce Core enabled, with module versions (drush pm:list or composer.lock).
• Which of those sites are internet-facing, and whether JSON:API or REST exposes commerce_order and related entities.
• Orders created or modified since the earliest plausible exposure date, with the account behind each change.
• Third-party hosts or managed Drupal providers that operate storefronts on your behalf.

Contain

• Upgrade Commerce Core to the fixed release on every exposed site [S1][S2].
• If you cannot upgrade today, restrict anonymous access to Commerce order routes and JSON:API commerce entities at the WAF or reverse proxy. This step is reversible.
• Before upgrading, snapshot the database and export web and Drupal logs, so order history and request evidence are preserved.
• Order or payment changes already fulfilled or refunded cannot be undone by patching. Flag them for finance review.

Eradicate

• Fix the root cause by applying the fixed Commerce Core version [S1][S2].
• The sources describe no persistence mechanism. Review for new admin accounts, role or permission changes, and modified Commerce configuration as a precaution (unsourced; see open questions).

Recover

• Before restoring normal operations, complete the order audit for inconsistencies that Drupal advises [S1], and reconcile orders with payment processor records.
• After restoring, monitor order-modification volume and anonymous requests to Commerce routes. Watch for a revised advisory with indicators.

Re-enter the loop when

• Drupal or another primary source publishes indicators, exploit requests or affected routes.
• Drupal corrects the affected or fixed version ranges.
• Exploitation is reported against fixed versions or other Commerce submodules.
• The order audit finds tampering on a site not in the initial inventory.

Debrief

• Record the patch time for each site, the audit results and any financial impact.
• Gap: no primary Drupal advisory in the source set, and no IoCs or log patterns published [S1][S2].
• Gap: the reported version ranges contradict the fixed versions.
• Gap: what attackers did with the bypass (read, modify or create orders) is not described.

Detection coverage — checked automatically

Checked automatically 2026-11-10 22:22Z from public sources: 4 published, 23 nothing found, 0 not machine-checkable, 0 failed. "Nothing found" means the public source answered and had nothing, as of that moment; a feed covers only its newest posts. Re-checked daily.

Exposure queries — generated automatically

Where each CVE comes from: CVE-2026-118539 — Drupal Commerce Core access-bypass flaw CVE-2026-118539 exploited in the wild. A product row answers "is the software from that story reachable from the internet", not "is this card about that software".

vuln:CVE-2026-118539

http.component:"Drupal Commerce"

Internet-wide count, trend

Shodan's count of matching services on the whole internet, one point a day; the scope (your ranges) is never part of it. A count moves with Shodan's crawl as much as with patching, so read the direction, not the digit.

NVD has not published CPE configurations for these CVEs yet, so only the CVE query is exact; the product queries use the name the campaign gives (Drupal Commerce Core) and are replaced by NVD's spelling at the daily re-check once it names the software.

Also tried under the name the card uses, nothing matched on Shodan: product:"Drupal Commerce Core", http.component:"Drupal Commerce Core", host.services: (software.product = "Drupal Commerce Core").

Banner spellings: a model read 1 from the NVD names and this card's text (former and marketing names, console titles); 1 matched something on Shodan and is shown above, the rest were dropped.

Scope every query in your own tool, never in a shared document: Shodan `net:<your_ranges>`, `org:"<your_org>"` or `hostname:<your_domain>` (or a Shodan Monitor network alert, which applies the scope for you); Censys `host.ip: <your_ranges>` or `host.dns.names: <your_domain>`. Then compare the banner version with the affected range. Generated automatically 2026-11-10 22:22Z from the CVE ids and NVD's CPE configurations, each Shodan query counted against Shodan itself; re-built daily with the coverage check.

Open questions

• The reported range '3.0.0 through 3.3.13' includes the stated fix 3.3.13, and '0.0.0 through 2.41' includes 8.x-2.41. What are the correct boundaries per the Drupal advisory?
• The story says exploitation is 'against unauthenticated attackers'. This likely means by unauthenticated attackers; confirm.
• The story's priority line cites '42,000+ sites' and 'KEV-listed-style'. Neither is confirmed in the source summaries, and CISA KEV listing is unverified.
• Which routes or entity fields are vulnerable, and what can an attacker read or change?
• The publication date of the Drupal advisory and the first observed exploitation date are unknown.

Sources

• [S1] https://www.bleepingcomputer.com/news/security/drupal-warns-of-critical-commerce-core-flaw-exploited-in-attacks/ · BleepingComputer
• [S2] https://thehackernews.com/2026/10/hackers-actively-exploit-highly.html · The Hacker News

Public OSINT only. AI-generated by the pipeline; structure follows the DAIR model from Dynamic Incident Response (Joshua Wright). Published automatically; a dismissed draft unpublishes it.