WordPress 7.0.2 addressed critical SQL injection and remote code execution issues and was pushed through forced updates. A successful update reduces future exposure, but it does not prove the site was not accessed before patching. Teams need a bounded evidence audit before declaring the incident closed or rotating everything without a timeline.
Use this for sites that were publicly reachable before WordPress 7.0.2, updated late, failed the forced update, show unexplained changes, or need defensible post-patch evidence.
Quick answer
Record the vulnerable and patched windows first. Preserve access, WAF, PHP, application, hosting, database, file, and deployment evidence. Verify core checksums and known plugin or theme sources, then inspect recently changed PHP, executable uploads, new administrators, application passwords, cron, scheduled actions, options, mu-plugins, must-use loaders, database users, sessions, outbound traffic, and persistence. A clean scan is one signal, not proof of no compromise.
What to check first
- Build a UTC exposure timeline from WordPress versions, update attempts, CDN and WAF logs, hosting access logs, PHP logs, deploys, backups, and alerts.
- Verify core checksums and compare plugins, themes, mu-plugins, drop-ins, wp-config.php, uploads, and web-root files against trusted sources.
- Audit users, administrators, application passwords, sessions, cron, scheduled actions, database accounts, options, webhooks, mail settings, and API credentials.
- Search for suspicious requests, changed files, encoded PHP, executable uploads, unknown outbound connections, persistence, and cleanup activity.
- Contain and rotate credentials according to evidence, rebuild from trusted sources when integrity cannot be established, and monitor after restoration.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the exposure timeline and preserve available logs and snapshots. | Build a UTC exposure timeline from WordPress versions, update attempts, CDN and WAF logs, hosting access logs, PHP logs, deploys, backups, and alerts. | WordPress 7.0.2 or later is installed and update failures are resolved. |
| Verify trusted code and inspect persistence outside core. | Verify core checksums and compare plugins, themes, mu-plugins, drop-ins, wp-config.php, uploads, and web-root files against trusted sources. | Core, plugin, theme, upload, mu-plugin, drop-in, and configuration evidence is reconciled. |
| Audit identities, credentials, scheduled execution, and outbound paths. | Audit users, administrators, application passwords, sessions, cron, scheduled actions, database accounts, options, webhooks, mail settings, and API credentials. | Accounts, sessions, application passwords, cron, actions, options, and outbound paths are accounted for. |
| Contain affected services and rebuild when integrity is uncertain. | Search for suspicious requests, changed files, encoded PHP, executable uploads, unknown outbound connections, persistence, and cleanup activity. | Containment, credential rotation, rebuild, monitoring, and disclosure decisions have owners. |
Why this usually happens
- Patching prevents use of the fixed path after installation, not before.
- Attackers can place persistence outside WordPress core files.
- Timestamp and log retention gaps can hide the exact entry window.
- Security scanners differ in signatures and cannot prove a negative.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
evidence,window,source,expected,actual,owner,decision
core,post-patch,checksum,match,match,platform,pass
uploads,exposure,file-list,no-php,shell.php,security,contain
users,exposure,admin-list,4,5,identity,investigate
logs,pre-patch,waf+access,quiet,encoded-post,security,escalate
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 |
|---|
| Patched before exposure | Logs and version timeline | Document lower-risk window |
| Late patch | Suspicious request before update | Escalate evidence review |
| Checksum mismatch | Changed core or unknown PHP | Contain and rebuild decision |
| No obvious artifact | Complete retained evidence | Monitor with stated uncertainty |
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.
- Freeze the exposure timeline and preserve available logs and snapshots.
- Verify trusted code and inspect persistence outside core.
- Audit identities, credentials, scheduled execution, and outbound paths.
- Contain affected services and rebuild when integrity is uncertain.
- Rotate scoped credentials and monitor the restored baseline.
Decision rule
Close the audit only when the vulnerable window is documented, code and persistence checks reconcile to trusted sources, identities and credentials are accounted for, and residual uncertainty plus monitoring is recorded.
Production verification checklist
- WordPress 7.0.2 or later is installed and update failures are resolved.
- Core, plugin, theme, upload, mu-plugin, drop-in, and configuration evidence is reconciled.
- Accounts, sessions, application passwords, cron, actions, options, and outbound paths are accounted for.
- Containment, credential rotation, rebuild, monitoring, and disclosure decisions have owners.
Field notes
- Preserve original evidence before cleanup.
- Do not publish sensitive indicators tied to the live site.
- Bring in incident-response help when customer or regulated data may be affected.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache changes, and schema work on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
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, investigate a potentially compromised WordPress site.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references