WordPress 7.0.3 fixes a multisite privilege-escalation issue affecting networks with user registration enabled, where a user could create a new site. A network update should be followed by a scoped review of registration policy, recently created sites, memberships, capabilities, and network-level changes.
Use this for universities, franchises, publishers, communities, SaaS-style multisite platforms, agency networks, and any WordPress multisite installation where users can register or site creation has ever been enabled.
Quick answer
Update the network to WordPress 7.0.3, record registration and site-creation settings, list recently created users and sites, map every site administrator to an approved owner, review role and capability changes, and test each allowed registration branch with fresh low-privilege accounts. Disable public registration temporarily if ownership cannot be established.
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 |
|---|
| Registration disabled | Anonymous visitor and new subscriber | Neither account nor site creation exceeds the documented policy |
| User registration | Fresh subscriber with verified email | The user receives only the intended account and no unintended site |
| Approved site creation | Authorized role and known domain | One site is created with expected owner, defaults, and audit record |
| Existing site | Recent unfamiliar site and owner | Ownership is approved or the site is contained with evidence preserved |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Patch the entire network | Record Network Settings values for registration, banned names, allowed email domains, welcome email, and new-site defaults. | Every network site and recent user maps to an approved owner or a documented containment action. |
| Freeze risky registration paths | Export users and sites created during the exposure window with registration time, owner, domain, path, status, and memberships. | Super-admin and site-administrator lists contain no unexplained identities. |
| Export users, sites, and memberships | Review super admins, site administrators, custom roles, capabilities, invitations, activation keys, and automation that creates sites. | Each registration branch produces exactly the expected account and site result. |
| Remove unauthorized access carefully | Inspect web, authentication, registration, email, and audit logs for site-creation requests and activation activity. | Network, SSO, provisioning, email, and audit logs preserve enough data to explain creation events. |
What to check first
- Record Network Settings values for registration, banned names, allowed email domains, welcome email, and new-site defaults.
- Export users and sites created during the exposure window with registration time, owner, domain, path, status, and memberships.
- Review super admins, site administrators, custom roles, capabilities, invitations, activation keys, and automation that creates sites.
- Inspect web, authentication, registration, email, and audit logs for site-creation requests and activation activity.
- Retest disabled registration, user-only registration, and approved site creation with disposable accounts after the update.
Field notes
- Export the site and membership record before deleting or archiving an unexpected site.
- Test with new accounts because existing memberships can hide the effective default role.
- Include mapped domains and archived sites when reconciling network inventory.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp core version --extra --network
wp site list --fields=blog_id,url,registered,last_updated,public,archived,deleted
wp super-admin list
wp user list --fields=ID,user_login,user_email,user_registered
# Compare recent sites with approved provisioning records and mail logs.
Why this usually happens
- Multisite separates network, site, and user permissions, which makes an apparently small registration path security-sensitive.
- Plugins, invitations, SSO, and provisioning jobs can change the effective policy beyond the Network Settings screen.
- A newly created site can host content, users, uploads, and integrations even when the main site appears unchanged.
Decision rule
Keep public site creation disabled when a recent site lacks an approved owner, a low-privilege fixture can exceed policy, provisioning logs are incomplete, or network and application settings disagree.
Production verification checklist
- Every network site and recent user maps to an approved owner or a documented containment action.
- Super-admin and site-administrator lists contain no unexplained identities.
- Each registration branch produces exactly the expected account and site result.
- Network, SSO, provisioning, email, and audit logs preserve enough data to explain creation events.
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.
- Patch the entire network
- Freeze risky registration paths
- Export users, sites, and memberships
- Remove unauthorized access carefully
- Retest and monitor provisioning
Mistakes to avoid
- Do not update only the primary site and assume the network is covered.
- Do not delete an unknown site before exporting its owner and activity.
- Do not test only with an existing administrator.
- Do not overlook plugin, SSO, invitation, or API provisioning paths.
Questions teams ask during testing
Which networks are specifically relevant?
The WordPress release calls out multisite with user registration enabled.
Should every recent new site be deleted?
No. Reconcile it to an approved request first and preserve evidence before containment.
Does disabling registration remove an unauthorized site?
No. It limits new activity but existing sites, users, memberships, and persistence still require review.
What to tell the client or owner
Share the network URL, registration settings, recent user and site exports, super-admin list, unexpected domains or paths, provisioning source, timestamps, and containment status.
When HandL WP should help
HandL WP can patch a multisite network, reconcile sites and owners, review roles and provisioning paths, preserve evidence, and build a repeatable registration fixture.
If this is active on a production site, audit a WordPress multisite network.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references