WordPress 7.0.2 was released on July 17, 2026 to address a facilitated SQL injection issue and a REST API batch-route confusion plus SQL injection path that can lead to remote code execution. WordPress.org recommends updating immediately and says forced auto-updates are enabled for affected versions. The practical job is to verify the version, update safely, and look for evidence that the site was touched before the patch landed.
Use this for production sites on WordPress 6.8, 6.9, 7.0, or the 7.1 beta line, including agency fleets where background updates may have started without a manual maintenance window.
Quick answer
Check the installed core version first. Patch affected branches to 6.8.6, 6.9.5, 7.0.2, or 7.1 Beta 2 as appropriate, then verify checksums, REST behavior, administrators, scheduled tasks, writable PHP files, and edge cache. Do not assume an auto-update notice proves every site completed successfully.
What to check first
- Inventory the exact WordPress version, update policy, last successful backup, PHP version, and whether the host attempted a forced background update.
- Capture core update logs and web access logs before rotation, focusing on unusual REST API batch requests, SQL errors, new PHP files, and unexpected administrator activity.
- Patch the correct maintained branch, confirm the final version from both WP-CLI and the admin dashboard, and run core checksum verification.
- Review administrator accounts, application passwords, active sessions, cron events, must-use plugins, uploads containing executable files, and recently modified PHP files.
- Test login, publishing, forms, checkout, REST API calls, scheduled jobs, cache behavior, and monitoring after the update rather than stopping at a green update screen.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Inventory every site | Inventory the exact WordPress version, update policy, last successful backup, PHP version, and whether the host attempted a forced background update. | WP-CLI and the dashboard report the intended patched branch, and core checksums pass. |
| Preserve useful logs | Capture core update logs and web access logs before rotation, focusing on unusual REST API batch requests, SQL errors, new PHP files, and unexpected administrator activity. | No unexplained administrator, application password, PHP file, must-use plugin, or cron event remains. |
| Install the branch patch | Patch the correct maintained branch, confirm the final version from both WP-CLI and the admin dashboard, and run core checksum verification. | REST API, login, publishing, forms, checkout, and scheduled tasks pass controlled tests. |
| Audit persistence paths | Review administrator accounts, application passwords, active sessions, cron events, must-use plugins, uploads containing executable files, and recently modified PHP files. | The origin and CDN serve the updated site while monitoring records no new SQL, REST, or permission errors. |
Why this usually happens
- Background updates can fail on file ownership, disk space, maintenance mode, or host-specific deployment controls.
- A core patch closes the vulnerable path but does not remove persistence if an attacker already gained access.
- CDN and page caches can make an updated origin look healthy while an API or admin workflow still fails.
- Agency inventories often contain forgotten staging sites or alternate domains that do not share the production update policy.
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
wp core update
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run_relative
find wp-content -type f -name '*.php' -mtime -14 -print
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Inventory every site
- Preserve useful logs
- Install the branch patch
- Audit persistence paths
- Monitor real workflows
Decision rule
Treat any affected and unpatched site as urgent. If logs, users, files, or scheduled jobs show unexplained changes, move from routine patching to incident response and rotate credentials after evidence is preserved.
What to tell the client or owner
Report the original and final core versions, update method, timestamps, checksum result, backup point, log retention, administrator review, file and cron findings, cache purge, workflow tests, and monitoring window.
Production verification checklist
- WP-CLI and the dashboard report the intended patched branch, and core checksums pass.
- No unexplained administrator, application password, PHP file, must-use plugin, or cron event remains.
- REST API, login, publishing, forms, checkout, and scheduled tasks pass controlled tests.
- The origin and CDN serve the updated site while monitoring records no new SQL, REST, or permission errors.
Mistakes to avoid
- Do not delete logs or suspicious files before recording timestamps, hashes, paths, and request evidence.
- Do not assume versions before WordPress 6.8 need this exact patch without checking the official branch guidance.
- Do not restore an old backup onto an exposed version and call the incident closed.
- Do not leave staging, alternate hostnames, or cloned sites outside the inventory.
Questions teams ask during testing
Was every older WordPress version affected?
The July 17 release notes say versions before 6.8 are not affected by these two issues. WordPress 6.8 is affected by the first issue, while 6.9 and 7.0 are affected by both. Use the official release page as the source of truth for branch updates.
Does a forced auto-update mean no action is needed?
No. Confirm the installed version and update result on each site. Then test business workflows and review signs of prior access because patching does not investigate activity that happened before the fix.
When HandL WP should help
HandL WP should help when a forced update fails, checksums do not pass, suspicious changes appear, or a revenue site cannot take a normal maintenance window. We can patch the right branch, preserve evidence, test critical workflows, and monitor the result.
If this is active on a production site, patch and verify the WordPress security release.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Fleet verification and post-patch evidence
Agencies should use the WordPress 7.0.2 forced auto-update failure dashboard to prove every affected runtime reached its patched branch. When pre-patch activity is unexplained, continue with the REST batch-route post-patch log hunt for request, database, filesystem, account, cron, and WAF evidence.
Core file integrity after the update
If post-update validation reports changed, missing, or unexpected core files, use the WordPress 7.0.2 core checksum failure fix to preserve file evidence, distinguish deployment drift from compromise, replace core safely, and verify the active release path.
Move the Core security checklist to WordPress 7.0.3
Use the WordPress 7.0.3 security update emergency checklist for the current stable security release, affected-surface tests, fleet verification, cache purge, and monitoring evidence.
Check for compromise after the patch
After updating, run the WordPress 7.0.2 post-patch compromise evidence audit across checksums, changed files, uploads, users, application passwords, cron, logs, persistence, credentials, and the vulnerable window.
Helpful references