Installing WooCommerce Subscriptions 9.1.0 closes the version gap named in the August security advisory, but it does not prove the account and capability surface stayed clean. An emergency update may involve temporary administrators, support access, staging copies, package uploads, and command-line credentials. A capability diff turns that activity into an auditable closeout instead of assuming every elevated account still belongs there.
Use this audit after an urgent Subscriptions update, a support-led package installation, or any incident where more people than usual touched production. It is especially useful for stores that split duties between owners, developers, fulfillment staff, finance staff, and external agencies.
Quick answer
Export administrators, shop managers, role definitions, active application passwords, and recent sessions from before and after the update. Match every change to a named request and owner. Remove temporary access, rotate credentials that crossed the incident boundary, and test one subscription workflow with a least-privilege account before closing the advisory.
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 |
|---|
| Administrator inventory | Pre-update export and current export | Every added, removed, or renamed user has an approved explanation |
| Shop manager boundary | Disposable shop manager account | Subscriptions can be managed without unrelated site administration access |
| Temporary support access | Support account and application password list | Expired access is revoked and remaining access has an owner |
| Session closure | Users involved in the rollout | Old sessions are destroyed after password or capability changes |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Save the current user and capability exports with a UTC timestamp. | Export every administrator and shop manager with user ID, email domain, registration date, and last known activity. | The final administrator and shop manager lists match the approved access register. |
| Approve, remove, or downgrade each changed account and record the decision. | Compare role capabilities before and after the update, including custom roles created by membership or support plugins. | No temporary application password, support session, or deployment account remains active. |
| Revoke temporary application passwords, SFTP keys, and support sessions. | List application passwords, hosting users, SFTP keys, database users, and support accounts used during deployment. | A least-privilege fixture can complete the intended subscription task and cannot reach unrelated settings. |
| Retest subscription administration with the intended least-privilege role. | Review plugin and mu-plugin files for code that grants capabilities or creates users during activation. | The closeout record includes before and after exports, decisions, owners, timestamps, and approver. |
What to check first
- Export every administrator and shop manager with user ID, email domain, registration date, and last known activity.
- Compare role capabilities before and after the update, including custom roles created by membership or support plugins.
- List application passwords, hosting users, SFTP keys, database users, and support accounts used during deployment.
- Review plugin and mu-plugin files for code that grants capabilities or creates users during activation.
- Map every elevated account to a ticket, owner, expiration time, and business reason.
Field notes
- Preserve user IDs and timestamps before deletion so a later log review can still explain the activity.
- Treat hosting, CDN, payment, and WordPress access as one incident boundary when the same person or secret touched all four.
- Do not publish usernames or email addresses in a client-facing report. Use internal IDs and role labels.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --format=csv
wp user list --role=shop_manager --fields=ID,user_login,user_email,user_registered --format=csv
wp role list --fields=role,name --format=table
wp cap list shop_manager
wp user application-password list 12
Why this usually happens
- Emergency maintenance often creates temporary accounts that survive after the technical work is complete.
- Custom plugins can add capabilities to existing roles without creating a visible new administrator.
- A staging or support credential may be reused on production even when the plugin package itself is trusted.
Decision rule
Close the access portion of the update only when every elevated identity has a named owner, justified capabilities, and an expiration or review date. Escalate any account, capability grant, or credential that cannot be tied to approved work.
Production verification checklist
- The final administrator and shop manager lists match the approved access register.
- No temporary application password, support session, or deployment account remains active.
- A least-privilege fixture can complete the intended subscription task and cannot reach unrelated settings.
- The closeout record includes before and after exports, decisions, owners, timestamps, and approver.
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.
- Save the current user and capability exports with a UTC timestamp.
- Approve, remove, or downgrade each changed account and record the decision.
- Revoke temporary application passwords, SFTP keys, and support sessions.
- Retest subscription administration with the intended least-privilege role.
- Attach the final diff, approver, and next quarterly review date to the security record.
Mistakes to avoid
- Do not remove an unexplained account before preserving its ID, timestamps, and relevant log evidence.
- Do not review WordPress users while ignoring hosting, SFTP, CDN, and payment accounts used in the same update.
- Do not assume a familiar username still belongs to the same person or email domain.
- Do not give shop managers administrator access just to make one subscription screen work.
Questions teams ask during testing
Does the 9.1.0 update create new administrators?
The advisory does not say that the fixed update should create administrators. This audit checks the surrounding deployment and incident activity, not an expected feature of the release.
Should every session be destroyed?
Destroy sessions for changed passwords, removed access, or incident participants. Avoid unnecessary disruption for approved users when evidence shows their sessions are safe.
How often should capabilities be reviewed?
Review them after security events, staffing changes, major plugin migrations, and on a recurring schedule appropriate to store risk.
What to tell the client or owner
Give the owner the fixed plugin version, exported user lists, capability diff, removed identities, rotated credentials, unresolved findings, least-privilege test result, approver, and next review date.
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, review WooCommerce access after an urgent update.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references