A WordPress update closes the vulnerability it was built to fix. It does not prove that nobody reached the site before the update arrived. That distinction matters after a serious security release.
WordPress 7.0.2 addressed one critical and one high-severity issue. The project also enabled forced updates for affected sites and released fixes for supported 6.8 and 6.9 branches. The official WordPress 7.0.2 release notice gives the exact affected and fixed versions.
If your dashboard now shows a fixed version, that is good news. Your next job is a WordPress post-patch security check: establish when the site updated, look for changes made before that time, and decide whether the evidence supports normal monitoring or a controlled cleanup.
This guide focuses on owner-safe checks. It does not reproduce an exploit or ask you to experiment on a live site.
Start with the right question
“Is WordPress updated?” and “Is this site clean?” are different questions.
The first has a simple answer. Confirm that WordPress runs 7.0.2, 6.9.5, 6.8.6, or another version that the official notice identifies as fixed for its branch. Our WordPress 7.0.2 owner checklist covers the update, cache, form, checkout, and smoke tests that should follow the patch.
The second question needs a timeline. A clean update may have landed before any unwanted activity. It may also have landed after an account, file, scheduled task, or database record changed. You need evidence from around the patch window before you can tell those situations apart.
Build a short incident timeline first
Write down four times before changing anything else:
- When the site installed the fixed WordPress version.
- When your last known-good backup completed.
- When monitoring first showed unusual traffic, errors, emails, or account activity.
- When an administrator last made an expected code or configuration change.
Hosting activity logs, update emails, backup history, deployment records, and WordPress audit logs can help. Use UTC or one clearly labelled time zone throughout. A mixed timeline creates avoidable confusion when server logs and WordPress timestamps differ.
Do not immediately delete a suspicious file or user if the site still serves safely. Record its name, timestamp, path, role, and related log entries first. That evidence can distinguish a compromise from a legitimate deployment and can reveal whether the same change exists elsewhere.
Run these six post-patch checks
1. Review administrator and privileged accounts
Open the WordPress Users screen and list every administrator. Confirm each person, email address, role, and creation date where your audit tooling provides it. Then check hosting, SFTP, SSH, database, CDN, and domain accounts.
Look for a new administrator, a familiar username with a changed email address, an unexpected application password, or a role that gained more access than it needs. Also review recent password-reset and new-user emails. An attacker does not need to leave an obvious name if an existing account already provides access.
If anything looks wrong, preserve the record, suspend the access path, and rotate credentials from a trusted device. Do not reuse the old password with a small variation.
2. Verify WordPress core and executable files
Compare WordPress core files with the official checksums for the installed version. WP-CLI can perform this comparison without replacing files. A failed checksum does not automatically prove a breach because some hosts add legitimate files, but every unexpected difference needs an explanation.
Review recently modified PHP files in the WordPress root, wp-admin, wp-includes, active plugins, active themes, and must-use plugins. Pay particular attention to files modified outside a known update or deployment window.
The uploads directory should normally contain media, not executable PHP. Treat an unexpected executable file there as a containment issue, not a routine cleanup task.
3. Check plugins, themes, and hidden loading paths
Confirm that every active and inactive plugin came from an approved source. Remove nothing until you know whether it supports the active site, but flag abandoned, nulled, unknown, or recently added components for review.
Inspect must-use plugins, drop-ins, and hosting-specific loaders as well as the ordinary Plugins screen. Files such as object-cache and advanced-cache drop-ins can be legitimate. Their origin, owner, and modification time should still match the stack you intended to run.
Compare active theme files with your repository, vendor package, or known-good deployment. A visual site check alone cannot reveal server-side code added to a theme file that rarely renders.
4. Review access and error logs around the patch window
Logs are most useful when you ask a specific question. Search the relevant time range for unexpected administrative requests, repeated failures followed by success, unusual REST requests, new login locations, PHP errors from unfamiliar paths, and outbound requests that your site does not normally make.
A single unusual request is not proof of execution. Correlate it with file changes, account activity, database records, or process logs. Our guide to WordPress error log monitoring explains how to turn noisy logs into an operational signal without exposing sensitive data.
Preserve the original logs before rotating or truncating them. Some hosts retain only a short window, so export the relevant period while it is available.
5. Inspect database persistence and scheduled work
A site can look normal while unwanted changes remain in the database. Review recent posts, pages, reusable blocks, widgets, menu items, redirects, SEO fields, and theme options for injected links or scripts. Check the WordPress address, site address, administrator email, default user role, and registration setting.
List scheduled WordPress events and compare them with known plugins. An unfamiliar event that runs often deserves investigation, especially when its callback does not belong to an installed component. Also review autoloaded options and active-session data for unexplained growth or recently added values.
A database search can damage serialized data if you use a naive text replacement. Take a backup and use WordPress-aware tools when a cleanup becomes necessary.
6. Prove that recovery is available
Identify the newest backup that predates suspicious activity, not merely the newest backup overall. Confirm that it includes both files and the database, can be downloaded, and belongs to the correct site.
Do not overwrite the live site just to see whether a backup works. Restore it to an isolated environment, scan it, compare it with the current site, and test the workflows that matter. Our WordPress backup restore test gives a practical recovery drill.
A backup taken after unwanted persistence appeared can faithfully restore the problem. That is why the timeline comes before the restore decision.
Know what counts as a real warning
Escalate the review when two or more independent signals support the same concern. Examples include:
- An unknown privileged account and a matching login event.
- An unexpected executable file and a request to that path.
- A changed option and an unexplained scheduled task that rewrites it.
- Outbound traffic from PHP and a recently modified plugin or theme file.
- Search spam, redirects, or altered pages that appear only to logged-out visitors.
Normal update activity can also look suspicious. Plugin updates modify many files at once. Cache systems write generated files. Backup tools create archives. A managed host may install a must-use plugin. Verify the source and timing before calling those changes malicious.
Contain first when the evidence is material
If the review finds a credible compromise, stop treating the task as ordinary maintenance. Preserve evidence, restrict access, and prevent the site from making the situation worse.
A controlled response usually follows this order:
- Record the current state and retain relevant logs.
- Restrict administrative and server access.
- Rotate WordPress, hosting, database, SFTP, SSH, CDN, email, and API credentials.
- Replace WordPress core, plugins, and themes with trusted copies.
- Remove persistence from users, scheduled events, files, and database records.
- Restore known-good content where replacement is safer than manual repair.
- Patch every component and verify configuration.
- Test the public site, forms, checkout, email, jobs, and integrations.
- Monitor closely for repeated indicators.
Do not “clean” only the first file a scanner names. A partial repair can remove a symptom while leaving the access path and persistence intact.
What a maintenance plan should do after a security release
A reliable plan should connect patching with verification. Installing an update is only one control.
For a business site, the operating routine should include an inventory of core, plugins, themes, and privileged accounts; tested backups; update and deployment records; uptime and error monitoring; regular integrity checks; and a clear escalation path when evidence conflicts.
Webless WordPress maintenance services are designed around that operational work: controlled updates, backups, monitoring, checks, and documented follow-up rather than a dashboard-only patch. The maintenance plan options show the current scope for sites that need the process handled consistently.
A 15-minute owner triage
If you cannot complete a full investigation immediately, do this minimum triage:
- Confirm the installed WordPress version matches a fixed release.
- Write down the update time and last known-good backup time.
- Review every administrator and application password.
- Check recently changed executable files and the uploads directory.
- Export available access and error logs for the relevant window.
- Review scheduled events and critical site settings.
- Escalate instead of deleting evidence when signals line up.
This triage cannot certify a site as clean. It can, however, separate a routine post-update check from a likely incident that needs containment.
Final answer: the patch closes the door, the review checks the room
WordPress 7.0.2 and its backports addressed the known core vulnerabilities. Owners should install the correct fixed version promptly. After that, a WordPress post-patch security check should verify what happened before and around the update.
Start with a timeline. Review accounts, files, plugins, themes, logs, database state, scheduled work, and backups. Correlate signals instead of trusting one scanner result. If the evidence points to compromise, preserve it and run a complete containment and recovery process.
That approach is less dramatic than guessing whether a site was “hacked.” It is also far more useful: it produces a defensible answer and a safer next action.