Drupal Commerce Security Incident Response: What to Do After the October 2026 Access Bypass

Tim Rabbetts | November 7, 2026

Drupal Commerce administrators have had to treat the 28 October 2026 security release as an incident-response event rather than a routine dependency update. Commerce Core 3.3.13 and 8.x-2.41 fixed several security issues, including SA-CONTRIB-2026-254, a highly critical access-bypass vulnerability rated 21/25. Drupal’s advisory states that the vulnerability was being actively exploited in the wild.

The maintainers subsequently reported attempts by malicious users to place fraudulent orders on live sites. That does not mean every affected installation was compromised, but it does mean that updating the module is only the first step. A production Commerce site should also establish whether suspicious orders, altered customer data, unusual API requests or administrative activity occurred before the patch was deployed. ([drupal.org](https://www.drupal.org/project/commerce/releases/3.3.13?utm_source=openai))

What changed on 28 October

The affected project is Drupal Commerce Core. Sites running Commerce 3.x should be on 3.3.13 or later, while the older 2.x branch requires 8.x-2.41 or later. The security release also addressed additional Commerce issues involving information disclosure, access bypass and cross-site request forgery, so selectively applying only one part of the release is not an appropriate remediation strategy.

SA-CONTRIB-2026-254 is particularly serious because it concerns access controls around routes and entity fields in a system that can create orders, calculate totals and initiate payment workflows. The advisory identifies the potential impact as financial rather than merely informational. A weakness in a public content site may expose data; a weakness in a shop can also affect stock, fulfilment, payment attempts, discounts and customer records.

The Drupal Security Team classified the issue as highly critical, with no authentication required in the advisory’s attack-complexity and privilege assumptions. The Canadian Centre for Cyber Security also warned that the vulnerability was being exploited in the wild. ([cyber.gc.ca](https://www.cyber.gc.ca/en/alerts-advisories/drupal-security-advisory-av26-1105?utm_source=openai))

First response: contain, preserve and patch

Do not begin by deleting suspicious orders or clearing logs. Those actions may remove the evidence needed to determine what happened. Use a short, controlled response sequence instead:

  1. Identify the deployed Commerce version and the time it was patched.
  2. Preserve application, web-server, CDN, WAF, payment-provider and administrative logs.
  3. Restrict high-risk operational actions if your business process allows it.
  4. Update Commerce Core using the project’s supported dependency-management workflow.
  5. Clear caches and run database updates where required.
  6. Review orders, users, API requests and administrative changes made before remediation.

For a site managed with Composer, begin from a clean working tree and record the current state:

git status --short
composer show drupal/commerce
drush status
drush core:status

The exact output will vary with your project template and Drush version, but the purpose is consistent: establish which code is deployed, which Drupal root is active and whether the update is being performed against the intended environment. Run these commands before changing dependencies and save the output with the incident record.

Update the supported Commerce branch

For a current Commerce 3.x project, the release page documents the following Composer constraint:

composer require 'drupal/commerce:^3.3' --update-with-dependencies

If your project already has an appropriate constraint and you want to update only the package and its dependencies, this is also a common approach:

composer update drupal/commerce --with-dependencies

Do not blindly copy either command into production. Review the resulting lock-file diff, test the update in a staging environment and confirm that the resulting version is at least 3.3.13. The release page lists 3.3.13 as compatible with Drupal 10.3 and Drupal 11. ([drupal.org](https://www.drupal.org/project/commerce/releases/3.3.13?utm_source=openai))

For a project remaining on Commerce 2.x, use the supported 2.x update path and confirm that the resolved package is at least 8.x-2.41. Avoid changing major branches during an emergency security deployment unless the migration has already been planned and tested.

Deploy the lock file, not a hand-built vendor directory

The production deployment should use the reviewed composer.lock file. A repeatable deployment might look like this:

composer install \
  --no-dev \
  --prefer-dist \
  --no-interaction \
  --optimize-autoloader

drush updatedb --yes
drush cache:rebuild

Whether drush updatedb is required depends on the release and the state of the site. Run it as part of the normal Drupal deployment process, but do not assume that every Composer update requires database changes. Review the update output and your deployment pipeline’s checks.

After deployment, verify the package actually installed on the running host:

composer show drupal/commerce
drush pm:list --type=module --status=enabled | grep -i commerce

If your platform builds an artefact in CI and promotes it between environments, verify the artefact’s commit, lock file and vendor directory rather than running Composer independently on the web server. That reduces the possibility of staging and production receiving different dependency graphs.

Preserve evidence before investigating transactions

Commerce investigations often fail because the site team looks only at the order table. An attacker may have interacted with several layers: the storefront, JSON:API, custom controllers, payment callbacks, session storage, a CDN or a third-party fraud service. Preserve the surrounding evidence before it expires.

Application and infrastructure evidence

Export or retain the following, using your organisation’s data-retention and privacy policies:

  • Drupal watchdog or structured application logs.
  • Web-server access and error logs.
  • Reverse-proxy, CDN and WAF request logs.
  • Authentication, password-reset and administrator activity logs.
  • Payment-provider events, authorisation attempts and webhook records.
  • Queue, cron and scheduled-task logs.
  • Deployment records showing when the vulnerable and fixed versions were active.
  • Database backups from before and after the update.

Record timestamps in UTC or include the timezone explicitly. This matters when correlating a Drupal request with a payment-provider event or a warehouse action. Keep the original exports read-only where possible, calculate hashes for evidence files and document who collected each item.

Do not put full payment-card data into a Drupal incident ticket or a shared Slack channel. Payment information, customer addresses and personal data should be handled according to your organisation’s PCI DSS, UK GDPR and internal incident-management requirements.

Establish the exposure window

Find the earliest deployment of the vulnerable Commerce version and the completion time of the fixed deployment. The investigation window should include both ends, with a safety margin for log ingestion delays:

git log --oneline --all -- composer.lock | head -20
git log -1 --format='%H %cI' -- composer.lock
git log -1 --format='%H %cI' -- web/modules/contrib/commerce

The commands above are useful only when the repository contains the relevant files and deployment history. In an artefact-based platform, use the CI/CD release record instead. The important output is not a particular Git command; it is a defensible answer to three questions:

  • When did the vulnerable code first become reachable?
  • When was the patched code serving requests?
  • Which public and authenticated interfaces were exposed during that period?

Review orders for fraud and state inconsistencies

Start with operationally meaningful indicators rather than assuming that every unusual order is malicious. Work with finance, customer service and fulfilment teams to identify:

  • Orders created without a corresponding normal checkout journey.
  • Orders with unusual totals, discounts, currencies or shipping destinations.
  • Repeated orders sharing an IP address, device fingerprint, email pattern or payment token.
  • Orders created or modified outside normal business hours.
  • Orders whose payment state, order state and fulfilment state do not agree.
  • Unexpected use of administrative or customer-facing API endpoints.
  • Orders using promotions, stock levels or price rules in ways that normal customers cannot reproduce.

Do not rely on the order’s current state alone. An attacker or a compromised integration may have caused a state transition that was later overwritten by a cron job, payment callback or staff member. Compare order history, payment-provider events and fulfilment records where those systems retain independent histories.

Commerce schemas and custom fields differ between installations, so avoid pasting an untested SQL query into production. Use the administrative interface or a read-only reporting replica first. If you need a database extract, have a developer inspect the actual schema and field storage generated by the site’s enabled modules.

A useful investigation report should capture the order identifier, creation and modification times, customer account, payment status, total, currency, IP-related evidence where lawfully retained, fulfilment status and the reason the order was flagged. Keep the original values as well as any corrected values.

Do not automatically refund or cancel suspicious orders

Refunding or cancelling every suspicious order can create a second incident. It may cause duplicate refunds, release stock incorrectly or interfere with payment-provider dispute processes. Instead:

  1. Place affected orders into a controlled review queue.
  2. Prevent fulfilment while the order is being assessed.
  3. Confirm payment settlement directly with the payment provider.
  4. Contact the customer through a trusted channel if their account may be affected.
  5. Document any cancellation, refund, capture reversal or stock adjustment.

If fraudulent orders were attempted, preserve the details even when the payment failed. Failed attempts can reveal the attacker’s method and help the payment provider or hosting team correlate activity across systems.

Check API and unpublished-content exposure

The 28 October release included an advisory concerning JSON:API access to unpublished product variations in particular circumstances. Sites with published products and unpublished variations should verify whether those variations could be retrieved by users who did not have permission to view them. ([drupal.org](https://www.drupal.org/security/home?page=1&utm_source=openai))

Review whether the site exposes JSON:API publicly, whether product and variation entities are available through it, and whether custom access handlers or contributed modules alter entity access. Also inspect any decoupled front end, mobile application or integration that caches API responses.

Public API routes should be tested as an anonymous user and as representative authenticated roles. A simple request can establish whether an endpoint responds, but a successful HTTP status alone does not prove that the response is authorised:

curl --silent --show-error \
  --header 'Accept: application/vnd.api+json' \
  'https://example.test/jsonapi'

For an actual entity endpoint, use the URL structure configured by the site and test only data that your security team has approved for investigation. Do not probe production with guessed identifiers or automated enumeration. Capture response headers and bodies in a controlled test environment wherever possible.

Pay special attention to caches. If private or unpublished data was returned with cacheable headers, a CDN or reverse proxy could have retained it beyond the original request. Review cache configuration, purge relevant objects and determine whether cache keys varied correctly by authentication state.

Review privileged activity and integrations

An access-bypass vulnerability does not automatically imply that administrator credentials were stolen. Nevertheless, review privileged activity during the exposure window:

  • New user accounts and changes to existing roles.
  • Changes to payment gateways, tax rules, promotions, shipping methods or stock.
  • Changes to product prices, variation availability and publication state.
  • New API keys, OAuth clients, webhook endpoints or integration credentials.
  • Unexpected configuration imports or deployment activity.
  • Changes to email templates, checkout panes or custom modules.

Rotate credentials when there is evidence that a secret may have been exposed, not merely because a security update was released. If the investigation cannot exclude access to a payment integration, consult the provider before rotating keys so that event history and webhook verification can be preserved.

Check custom Commerce code as well. A patched core module cannot compensate for a controller that bypasses entity access checks, trusts client-supplied prices or exposes an order manipulation route without an appropriate permission and CSRF strategy.

Testing the remediation

A security update should be tested functionally and from an authorisation perspective. At minimum, cover:

  • Anonymous browsing of products and variations.
  • Customer checkout and payment return flows.
  • Order viewing by customers, staff and administrators.
  • Product and variation creation, editing and publication.
  • Promotion, coupon, tax and shipping calculations.
  • JSON:API or other public integrations.
  • Payment webhooks and asynchronous order updates.
  • Queue workers, cron and fulfilment exports.

For access-control tests, build a small role matrix rather than testing only as an administrator:

Actor Expected access Important checks
Anonymous visitor Published catalogue and public checkout entry points only No unpublished variations, customer records or staff routes
Customer Own account and own orders Cannot read or alter another customer’s order
Commerce staff Operational order and catalogue functions Permissions match the staff member’s business role
Administrator Configuration and security operations Administrative actions require appropriate authentication and CSRF protection

Automated tests should assert both positive and negative behaviour. A test that proves a customer can view their own order is useful; a test that proves the same customer cannot view another customer’s order is essential.

Make the next security release less disruptive

The October release is a reminder that Drupal security maintenance is an operational capability, not a calendar reminder. Drupal published 39 contributed-project advisories on 28 October, and Commerce advisories accounted for a substantial part of that release day. Community reporting also highlighted the need to distinguish the advisories that affect a particular site from those that apply to unrelated projects. ([drupalaid.com](https://www.drupalaid.com/blog/which-drupal-security-updates?utm_source=openai))

Maintain a current software inventory containing Drupal core, contributed modules, themes, Composer packages, PHP, database software, reverse proxies, CDN integrations and payment services. For each production site, record:

  • The supported branch and end-of-life date.
  • The person or team responsible for emergency updates.
  • The normal security deployment path.
  • Rollback and database-restore procedures.
  • Business owners for payments, fulfilment and customer communications.
  • Log retention and access arrangements.

Run dependency checks continuously, but do not treat an automated report as a replacement for Drupal’s security advisories. A package can be present in a lock file without being enabled, or an enabled module can be affected only under a particular configuration. Conversely, a custom integration may expose functionality that the advisory describes as requiring additional conditions.

composer audit
composer outdated "drupal/*" --direct

Use these commands as signals for review, not as an untested production-remediation script. Check the Composer version used by your build environment and confirm that your audit tooling understands the project’s advisory sources.

Conclusion

The correct response to the Drupal Commerce incident is two-track: patch the vulnerable package immediately, then investigate the period in which the vulnerable code was exposed. The fixed version protects future requests; it cannot explain or reverse suspicious orders, altered configuration or data that may already have been accessed.

Commerce teams should therefore treat the 28 October release as a trigger for a documented security review. Verify the resolved version, preserve evidence, examine order and payment histories, test API authorisation, involve the right operational teams and record the outcome. That process is more valuable than a one-off emergency command because the same discipline applies to the next Drupal core, contributed-module or third-party dependency advisory.

For current remediation details, use the official Commerce release information and Drupal security advisory pages as the source of truth. The Commerce 3.3.13 release page identifies the fixed release and its compatibility, while the Drupal advisory records the severity and active-exploitation status of SA-CONTRIB-2026-254. ([drupal.org](https://www.drupal.org/project/commerce/releases/3.3.13?utm_source=openai))