After the urgent WordPress 7.0.2 security update, wp core verify-checksums can report missing, changed, or unexpected core files. That result does not by itself prove malware. It can also expose an incomplete update, wrong locale package, deployment artifact, host patch, permission failure, or stale release directory. The safe response preserves evidence before replacing files.
Use this for administrators, agencies, and incident responders validating WordPress 7.0.2 after automatic or manual updates. Treat unexplained PHP files, recent privileged accounts, suspicious requests, or changed configuration as a security investigation rather than a simple reinstall.
Quick answer
Record the installed version and locale, save the exact checksum output, hash and stat every flagged path, and identify whether it is missing, modified, or unexpected. Compare deployment history and host documentation, inspect surrounding security evidence, then replace core from the matching official package without overwriting wp-content or wp-config.php. Run checksums and functional tests again.
What to check first
- Confirm wp core version, locale, installation path, release symlink target, PHP user, filesystem owner, update method, and the timestamp the 7.0.2 update completed.
- Run the checksum command from the actual WordPress root and preserve stdout, stderr, exit code, UTC time, and the command version before changing any file.
- For each mismatch capture path, file type, size, owner, mode, modification time, SHA-256 hash, deployment release, and whether the official package should contain it.
- Review update logs, deployment logs, WAF and web access events, administrator changes, scheduled tasks, mu-plugins, wp-config.php, and uploads for evidence that broadens the incident.
- After replacement, test wp-admin, REST, cron, media, login, cache, and one critical business flow in addition to rerunning checksums.
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 |
|---|
| Preserve checksum and filesystem evidence | Confirm wp core version, locale, installation path, release symlink target, PHP user, filesystem owner, update method, and the timestamp the 7.0.2 update completed. | The installed version and locale match the checksums used. |
| Classify every missing, changed, or unexpected path | Run the checksum command from the actual WordPress root and preserve stdout, stderr, exit code, UTC time, and the command version before changing any file. | Every flagged path has a documented cause or incident owner. |
| Escalate unexplained changes into incident response | For each mismatch capture path, file type, size, owner, mode, modification time, SHA-256 hash, deployment release, and whether the official package should contain it. | A second checksum run returns clean after the controlled replacement. |
| Replace core from the matching official package | Review update logs, deployment logs, WAF and web access events, administrator changes, scheduled tasks, mu-plugins, wp-config.php, and uploads for evidence that broadens the incident. | Admin, REST, cron, media, login, cache, and the business workflow pass from the live release path. |
Why this usually happens
- A failed or interrupted update can leave a mixed core version.
- A non-default locale must be checked against the matching package.
- Managed hosts sometimes patch or wrap core files and should document that ownership.
- Release symlinks or containers can point traffic at a different tree than the shell command.
- Attackers may add files that official checksums report as unexpected, but incident scope requires more evidence.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
cd /var/www/example/current
wp core version --extra
wp core verify-checksums --include-root --locale=en_US
find wp-admin wp-includes -type f -print0 | xargs -0 sha256sum > /secure-evidence/core-sha256.txt
# Record ownership and timestamps before replacing any flagged path.
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.
- Preserve checksum and filesystem evidence
- Classify every missing, changed, or unexpected path
- Escalate unexplained changes into incident response
- Replace core from the matching official package
- Clear opcode cache and verify checksums plus workflows
Decision rule
Use a clean core replacement only when evidence supports an update or deployment failure with no sign of broader compromise. If ownership is unknown, PHP files appear outside expected locations, privileged access changed, or requests align with file modifications, preserve the system and investigate credentials, database, persistence, and logs before cleanup.
What to tell the client or owner
Report every mismatch with path, official expectation, hash, owner, timestamp, explanation, action, and post-fix result. State whether the case was classified as deployment drift, managed-host modification, failed update, or security incident.
Production verification checklist
- The installed version and locale match the checksums used.
- Every flagged path has a documented cause or incident owner.
- A second checksum run returns clean after the controlled replacement.
- Admin, REST, cron, media, login, cache, and the business workflow pass from the live release path.
Mistakes to avoid
- Do not delete unexpected files before hashing and recording them.
- Do not run checksums from an old release directory that does not serve traffic.
- Do not overwrite wp-content or wp-config.php during a core replacement.
- Do not assume a clean checksum proves accounts, database, uploads, and credentials are clean.
Questions teams ask during testing
Does a checksum warning always mean WordPress was hacked?
No. It is evidence of a file difference. Classify the difference using package, locale, deployment, ownership, timestamps, and security evidence.
Can I use wp core download --force?
It can replace core files, but preserve evidence first, use the matching version and locale, protect content and configuration, and verify the active release path afterward.
When HandL WP should help
Bring in HandL WP when the issue affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, investigate a WordPress checksum failure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Use checksum failures as an incident triage starting point
For a version-independent workflow, use the WP core checksum malware triage runbook. It separates wrong version or locale, partial deployment, modified official files, unknown root files, trusted replacement, persistence review, and final verification.
Helpful references