WordPress 7.0.2 fixed a REST API batch-route confusion and SQL injection path that can lead to remote code execution on affected branches. A successful update stops the known vulnerable behavior, but unexplained requests, SQL errors, file writes, accounts, or scheduled tasks from before the patch still require review.
Use this for affected WordPress 6.9 and 7.0 sites, the affected 7.1 beta line, and incident teams reviewing a site where public exposure or suspicious activity is plausible.
Quick answer
Preserve logs before they rotate. Search the pre-patch window for unusual wp-json batch requests and correlate timestamps with SQL or PHP errors, WAF events, new or modified PHP files, administrator changes, application passwords, sessions, cron, must-use plugins, uploads, and outbound callbacks. Escalate unexplained correlated evidence to incident response.
What to check first
- Define the exposure window from the last known patched state, release and update timestamps, host snapshots, and log retention limits.
- Preserve web, CDN, WAF, PHP, database, authentication, file-integrity, and deployment logs with timestamps and access controls.
- Find unusual REST batch routes, methods, payload sizes, status patterns, repeated encoded input, SQL errors, PHP warnings, and unexpected outbound requests.
- Review administrators, application passwords, active sessions, cron events, must-use plugins, drop-ins, uploads containing executable files, and recently modified PHP.
- Hash and record suspicious artifacts before containment, rotate credentials based on exposure, patch dependencies, and monitor the same indicators after recovery.
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 |
|---|
| Define and preserve the window | Define the exposure window from the last known patched state, release and update timestamps, host snapshots, and log retention limits. | The site runs the correct patched branch and core checksums pass. |
| Correlate request and error logs | Preserve web, CDN, WAF, PHP, database, authentication, file-integrity, and deployment logs with timestamps and access controls. | All suspicious timestamps have correlated request, system, and change evidence. |
| Audit persistence surfaces | Find unusual REST batch routes, methods, payload sizes, status patterns, repeated encoded input, SQL errors, PHP warnings, and unexpected outbound requests. | Unexplained users, credentials, files, cron, and sessions are contained and documented. |
| Contain and rotate by evidence | Review administrators, application passwords, active sessions, cron events, must-use plugins, drop-ins, uploads containing executable files, and recently modified PHP. | Monitoring shows no recurrence across REST, authentication, filesystem, and outbound indicators. |
Why this usually happens
- Web logs can show the request while database or PHP logs carry the meaningful failure signal.
- An attacker can establish persistence outside WordPress core, so replacing core files alone is incomplete.
- CDN or WAF logging may use a different timezone and request ID than the origin.
- Routine plugin updates and deployments create file changes that must be separated from unexplained modifications.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
zgrep -Ei 'wp-json|batch' /var/log/nginx/access.log* | tail -200
rg -n 'SQL|wpdb|fatal|warning' wp-content/debug.log
find wp-content -type f -name '*.php' -newermt '2026-07-01' -print
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list --fields=hook,next_run,next_run_relative
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.
- Define and preserve the window
- Correlate request and error logs
- Audit persistence surfaces
- Contain and rotate by evidence
- Retest and monitor indicators
Decision rule
One odd request is not proof of compromise, but a request correlated with unexplained SQL behavior, file changes, privileged access, persistence, or outbound traffic should be handled as an incident until explained.
What to tell the client or owner
Share the exposure window, patch time, log sources and timezones, request IDs, relevant status and error patterns, artifact hashes, user and cron findings, credential rotations, containment actions, and monitoring period.
Production verification checklist
- The site runs the correct patched branch and core checksums pass.
- All suspicious timestamps have correlated request, system, and change evidence.
- Unexplained users, credentials, files, cron, and sessions are contained and documented.
- Monitoring shows no recurrence across REST, authentication, filesystem, and outbound indicators.
Mistakes to avoid
- Do not publish exploit details or unsafe payload examples.
- Do not remove artifacts before recording paths, hashes, ownership, and timestamps.
- Do not treat a clean core checksum as proof that wp-content and credentials are clean.
- Do not rotate credentials before preserving enough evidence to understand scope unless active harm requires immediate containment.
Questions teams ask during testing
Does every REST batch request indicate exploitation?
No. WordPress and plugins can use REST APIs legitimately. Classify route, method, authentication, payload shape, response, source, frequency, and correlated changes.
How far back should logs be reviewed?
Start with the period the affected version was publicly reachable and expand when the first suspicious indicator, unknown change, or missing log segment requires it.
When HandL WP should help
HandL WP can preserve and correlate the WordPress, host, CDN, WAF, database, and file evidence, contain persistence, recover the site, and monitor the patched environment.
If this is active on a production site, investigate suspicious WordPress activity.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references