The August 5 WooCommerce advisory says WooCommerce Subscriptions should be updated to version 9.1.0 or later immediately. A security-only build may be appropriate when a store cannot accept a broader release, but downloading a ZIP and seeing a new version number is not enough. The team still needs package provenance, a rollback point, renewal fixtures, webhook evidence, and an origin-level version check.
Use this checklist for stores running WooCommerce Subscriptions where renewals, saved payment methods, customer account actions, scheduled jobs, or custom subscription code make an emergency plugin update operationally sensitive.
Quick answer
Obtain the security-only package through WooCommerce support, record its version and checksum, install it on an isolated production copy, and run one controlled renewal through payment, webhook, order note, email, and Action Scheduler. Deploy to production only after the fixture passes, then verify the active origin files report WooCommerce Subscriptions 9.1.0 or later.
What to check first
- Confirm the ZIP came from the WooCommerce account or support case and record the filename, checksum, ticket, and download time.
- Capture the current plugin version, database backup, active subscription count, next renewal window, and custom subscription integrations.
- Install the package on staging and compare plugin files, activation state, database notices, and scheduled actions before testing payment flows.
- Run renewal, manual payment retry, cancellation, reactivation, and customer payment-method change fixtures with disposable records.
- Recheck the production origin version and file checksum after deployment instead of trusting an agency dashboard cache.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Open or confirm the WooCommerce support case and obtain the approved fixed package. | Confirm the ZIP came from the WooCommerce account or support case and record the filename, checksum, ticket, and download time. | Production and staging report WooCommerce Subscriptions 9.1.0 or later from the active origin files. |
| Create a restorable backup and an isolated staging copy with payment credentials made safe. | Capture the current plugin version, database backup, active subscription count, next renewal window, and custom subscription integrations. | A controlled renewal creates one payment, one renewal order, the expected events, and no duplicate scheduled action. |
| Install the package and run the subscription workflow matrix with recorded IDs and timestamps. | Install the package on staging and compare plugin files, activation state, database notices, and scheduled actions before testing payment flows. | Customer cancellation, reactivation, and payment-method workflows still follow store policy. |
| Deploy to production, clear only relevant caches, and verify the active origin package. | Run renewal, manual payment retry, cancellation, reactivation, and customer payment-method change fixtures with disposable records. | The deployment record includes package checksum, backup, fixture IDs, owner, observation window, and closure evidence. |
Why this usually happens
- A security-only package may not appear in the normal update screen and can be confused with an older cached download.
- Subscription stores depend on payment gateway, webhook, Action Scheduler, email, and custom-code contracts that a version screen cannot test.
- Staging can report success while production runs a different PHP version, object cache, gateway mode, or plugin file set.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin status woocommerce-subscriptions
wp plugin get woocommerce-subscriptions --fields=name,status,version,update --format=json
shasum -a 256 woocommerce-subscriptions-9.1.0.zip
wp plugin install ./woocommerce-subscriptions-9.1.0.zip --force
wp plugin get woocommerce-subscriptions --field=version
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Automatic renewal | Active test subscription with valid sandbox token | Renewal order is paid once and expected webhook and email are recorded |
| Failed renewal | Decline test method | Order follows the configured retry path without duplicate charges |
| Customer action | Cancel and reactivate an eligible fixture | Status, dates, notes, and account display remain consistent |
| Scheduled action | Observe the renewal hook before and after update | One due action completes and no unexpected backlog appears |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Open or confirm the WooCommerce support case and obtain the approved fixed package.
- Create a restorable backup and an isolated staging copy with payment credentials made safe.
- Install the package and run the subscription workflow matrix with recorded IDs and timestamps.
- Deploy to production, clear only relevant caches, and verify the active origin package.
- Watch renewals, failed actions, gateway webhooks, and support contacts through the agreed observation window.
Decision rule
Proceed when the package source is trusted, the origin reports 9.1.0 or later, and the controlled renewal matrix passes. Stop and escalate if file provenance is unclear, the plugin remains below the fixed version, or renewal behavior changes in a way that cannot be explained by the fixture.
Production verification checklist
- Production and staging report WooCommerce Subscriptions 9.1.0 or later from the active origin files.
- A controlled renewal creates one payment, one renewal order, the expected events, and no duplicate scheduled action.
- Customer cancellation, reactivation, and payment-method workflows still follow store policy.
- The deployment record includes package checksum, backup, fixture IDs, owner, observation window, and closure evidence.
Field notes
- Schedule the deployment outside the densest renewal window, but do not delay an urgent security update for a perfect maintenance window.
- Keep customer names and full payment identifiers out of the change record. Order, subscription, event, and action IDs are usually enough.
- If the store cannot update, document the compensating control and an expiration time rather than marking the site protected.
Questions teams ask during testing
Why use a security-only build?
It can provide the vulnerability fix while reducing unrelated change, but WooCommerce support should confirm the package and applicable version.
Does version 9.1.0 prove the store is safe?
It proves the reported plugin version meets the advisory threshold. A post-update compromise audit and workflow verification are still separate tasks.
Should renewals be paused?
Only when the controlled evidence shows the update or incident makes charging unsafe. A blanket pause can create a larger billing problem.
Mistakes to avoid
- Do not download a security ZIP from an unverified mirror or a forwarded chat attachment.
- Do not overwrite production before proving a backup can be located and restored.
- Do not use a live customer subscription as the first renewal test.
- Do not mark the advisory closed from a remote dashboard version alone.
What to tell the client or owner
Give the owner the current and target versions, package checksum, support-case reference, backup location, fixture subscription ID, payment event ID, scheduled-action result, deployment time, and observation-window owner.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, verify a WooCommerce security update.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references