Drupal Commerce Security Advisory: Update and Audit Your Store

If a Drupal security advisory covers your Commerce store, read it today, update Commerce Core to the fixed version it lists, then review your recent orders, user accounts and payment settings.

This post is for store owners and the people who look after their Drupal sites. You will get a plain-English explanation of what an access bypass is, a step-by-step update routine, and an audit checklist you can finish in an afternoon. We do not quote version numbers here. Those must come from Drupal's own advisory, and we point you to it below.

What is an access bypass in Drupal Commerce?

Drupal Commerce is the add-on (a "module") that turns a Drupal site into an online store. It handles products, carts, orders and payments. Its core code is called Commerce Core.

An access bypass is a bug that lets someone do or see something they should not be allowed to. Normally Drupal checks who you are and what you may do. With a bypass, one of those checks fails or gets skipped. In a store, that could touch things like order data, customer details or admin-only actions. The exact effect depends on the specific flaw.

Security people call this class of bug "broken access control." OWASP lists it as a top web application risk.

What matters for you: the Drupal Security Team publishes the real details, including which versions are affected and which are fixed. Use those details, not a blog summary or a forum post.

Step 1: Read the official advisory first

Drupal posts every security advisory at drupal.org/security. Open it and find the Commerce entry. Write down these items:

• Advisory ID and date. This helps you note when you became aware of it.
• Affected versions. Compare them with the version you run.
• Fixed versions. This is the version you need to reach.
• Risk level and any conditions. Some bugs only matter if a certain feature or setting is on.
• Workarounds, if any. Updating is still the real fix.

If a news article gives a version number that does not match the advisory, trust the advisory. The advisory is the primary source. You can also check the Commerce project page for release notes.

Match the project name (Commerce) and the date on the advisory page itself.

Step 2: Find out which version you run

You can see this in two places.

1. In the admin area, go to /admin/reports/status (Reports, then Status report) and /admin/reports/updates (Available updates). Drupal flags modules with security updates.
2. If you have command-line access, run this from your project folder:

composer show drupal/commerce

The versions line shows what is installed. You can also run composer audit, which checks your installed packages against known security advisories.

Step 3: Back up, then update

Take a fresh backup of the database and files first. If your host offers snapshots, use one. Test the update on a staging copy if you have one. Then update through Composer, which is how Drupal 8 and later sites manage modules (see Drupal's updating guide).

composer update drupal/commerce --with-dependencies
drush updb -y
drush cr

If composer show drupal/commerce still shows a version below the fixed one, your composer.json constraint is holding it back. Run composer require "drupal/commerce:^2" --update-with-dependencies (use ^3 instead if you run the 3.x branch), then run the update steps again.

What these do:

• composer update downloads the new code.
• drush updb runs any database updates the new code needs.
• drush cr clears caches so Drupal uses the new code.

If you do not use Drush or Composer, ask your developer or host to do it. Do not edit module files by hand. After the update, run composer show drupal/commerce again and confirm the version is at or above the fixed version for your Commerce release branch (for example 2.x or 3.x).

Place a test order after updating. Check that the cart, checkout and payment all work.

Step 4: Audit your recent orders

An update closes the hole going forward. It does not tell you whether someone used it before. So look back. Start with the period before you updated, and go back as far as your logs and records allow.

In the admin area, open /admin/commerce/orders and look for:

• Orders you do not recognize, or orders with odd emails.
• Orders that were edited or had their state changed without a clear reason.
• Unexpected refunds, discounts, free orders or changed totals.
• Orders belonging to customers who say they never placed them.

If you have database access, you can list the most recently changed orders directly. This is a read-only query:

drush sql:query "SELECT order_id, mail, state, total_price__number, FROM_UNIXTIME(changed) AS changed FROM commerce_order ORDER BY changed DESC LIMIT 50"

This works on MySQL or MariaDB. Skim the list for anything that stands out.

Step 5: Audit user accounts

A common next move after an access problem is to create or upgrade an account. So check who can log in.

1. Open /admin/people and sort by newest. Look for accounts you did not expect.
2. Filter by role. Look at who has Administrator or any store manager role.
3. Remove or block accounts you cannot explain. Do not delete first if you want to keep evidence. Blocking is safer.
4. Reset passwords for admin and staff accounts, and turn on two-factor authentication if your site supports it.

Optional command-line views:

drush sql:query "SELECT uid, name, mail, FROM_UNIXTIME(created) AS created, FROM_UNIXTIME(access) AS last_access FROM users_field_data ORDER BY created DESC LIMIT 25"
drush sql:query "SELECT entity_id AS uid, roles_target_id AS role FROM user__roles WHERE roles_target_id = 'administrator'"

The second query lists every user with the default administrator role. If you made custom roles, check those too.

Step 6: Check your payment settings

A store is a target because it touches money. After an access issue, confirm nobody changed how payments work.

Go to /admin/commerce/config/payment-gateways and check each gateway:

• Mode. Is it in Live mode, as you expect? A gateway left in Test mode can quietly record orders without taking money.
• Credentials. Do the API keys and account IDs match your payment provider's dashboard?
• Return and notification URLs. These should point to your own site only.
• Other settings. Look at anything that changed recently.

Then log in to your payment provider's dashboard (not through a link in an email). Review recent payouts, refunds and any changes to your bank details. If anything looks off, contact the provider and rotate your API keys.

Step 7: Look at logs and watch for changes

Open /admin/reports/dblog (Recent log messages) and look for access denied errors, repeated failed logins or admin actions at strange hours. Also ask your host for web server access logs if they keep them. Many hosts only keep a short window, so ask early.

If you find signs of a break-in, switch to our website hacked guide for containment steps.

Quick audit checklist

What this does not tell you

A clean audit is a good sign, not a guarantee. Old logs may be gone, and subtle changes are easy to miss. Be honest with yourself about how far back you could look.

If you handle customer data and cannot rule out misuse, check the privacy and breach-notice rules where you and your customers live. A lawyer or your payment provider can advise you on that.

How to catch the next one sooner

Unpatched software is a common way stores get into trouble. Build a small habit:

• Subscribe to Drupal's security announcements and check them weekly.
• Update modules soon after a security release.
• Keep staff accounts to the minimum and remove old ones.
• Run a quick outside check. Our free website security check looks at your site from the outside, with no login and no card. It will not detect this specific Commerce bug, but it is a fast way to spot easy gaps.

If you wonder how exposed a store really is, our guide is my website hackable explains what an outsider can and cannot see.

Key takeaways

• Read the official advisory at drupal.org/security. Take the affected and fixed Commerce versions from there only.
• Back up, update with Composer, run drush updb and drush cr, then confirm the version and test a checkout.
• Audit recent orders and user accounts, because an update does not undo anything that already happened.
• Check payment gateway mode, credentials and URLs, then review your payment provider's dashboard.
• If something looks wrong, block suspicious accounts, rotate keys and follow our website hacked steps.

Want a human to check your store?

If you would like a person to look at your store, the Circuit audit is $49 one-time. A security engineer manually reviews your site and writes up every issue with evidence and exact fixes. It is a focused small-site audit, not a multi-week enterprise pentest or a compliance certificate. It will not replace updating Commerce today.