WordPress Core Under Active Exploitation: Verify the Fix and Investigate Possible Compromise
Tech GuruQuick Answer
Contain an affected site and preserve the vulnerable-period evidence, then verify a supported patched release on the actual serving files. Core checksums are one integrity check, not proof that the database, users, plugins, uploads or host are clean. Inspect those layers separately with trusted tools and rebuild from known-good software and reviewed content when the evidence cannot support in-place recovery. A patch does not erase prior access or revoke stolen credentials.
Patch
Verify the actual branch and fixed release, including advisory-specific courtesy backports where used; these do not establish continuing branch support.
Verify
Use WP-CLI and hosting tools to compare core files and look for unknown PHP.
Inspect
Attackers often persist through admin users, MU-plugins, scheduled tasks, web shells, or modified themes.
Rebuild
Restore clean content into a known-good environment when logs or filesystem evidence cannot support in-place recovery.
Decision Matrix
| Area | What to Check | Operational Standard |
|---|---|---|
| Version | Core branch, fixed backport, PHP, database, plugin/theme versions | Every affected branch is on a fixed release. |
| Integrity | Core checksums, unknown PHP, writable paths, plugin/theme diffs | Core matches upstream; custom code is expected and versioned. |
| Persistence | Admin users, app passwords, cron, MU-plugins, uploads, database options | No unknown users, jobs, web shells, or hidden loaders remain. |
| Recovery | Off-host backup, staging restore, credential rotation, cutover plan | Clean rebuild is ready if in-place trust fails. |
Verify The Fixed Branch
The July 17 release fixes both CVE-2026-60137 and CVE-2026-63030 in 7.0.2 and 6.9.5. Version 6.8.6 fixes the first issue; the second does not affect that branch. Versions before 6.8 are outside these two advisories, not necessarily safe or supported. These are historical fix floors. WordPress officially supports only its latest version; older backports are a courtesy. Verify the actual serving build and select a current supported release rather than trusting an update notification.
Use WP-CLI when available, and compare the output to the official release post and CISA KEV entries. If the site is managed by a host, panel, immutable image, or deployment pipeline, verify the live filesystem and database rather than trusting a control-panel summary.
On a potentially compromised site, ordinary WP-CLI inventory commands can execute installed PHP. Use a trusted runtime, binary, working directory and CLI configuration in an isolated analysis environment with a preserved snapshot, no production secrets and controlled network access. Follow the core checksum procedure, specifying the independently recorded version and locale; this command avoids loading WordPress. Do not disable TLS verification to fetch checksums.
- Compare core files and unexpected root files with the official release. Preserve mismatches before replacing anything.
- Review plugins, themes, MU-plugins and host configuration statically before bootstrapping a clone. Skipping ordinary plugins does not skip MU-plugins.
- Inventory administrator accounts, application passwords, cron and database options from a protected database copy or a reviewed isolated clone. Never treat a successful command on an untrusted host as independent assurance.
Look Where WordPress Compromise Usually Persists
Core files are only one layer. A site can have clean core checksums and still be compromised through an administrator account, application password, modified theme, malicious plugin, MU-plugin, cron job, upload directory PHP file, injected option, or hosting-level scheduled task.
Inventory before deleting. If you remove evidence before preserving it, you may lose the timeline needed to decide whether passwords, salts, database credentials, SFTP accounts, CDN credentials, or deployment keys were exposed.
- Compare administrator accounts to the expected list.
- Review application passwords, REST clients, and recently created users.
- Inspect
wp-content/mu-plugins, plugin directories, active themes, and uploads for unexpected PHP. - Check WordPress cron and host cron for unknown commands or callbacks.
- Review web server, PHP, WAF, and database logs for the vulnerable route and post-exploitation behavior.
When To Rebuild Instead Of Clean In Place
In-place cleanup can be reasonable for a failed probe or a small, well-contained finding. Rebuild becomes the better answer when you find unknown PHP, altered core files, created admins, unexplained cron, gaps in logs, or signs that the attacker reached the database or hosting account.
A clean rebuild starts from fresh WordPress core, trusted plugins and themes from known sources, reviewed uploads, a database export inspected for suspicious users/options, new salts, new passwords, and a WAF/proxy rule set that blocks the previous route while the site is being verified.
Validation Checklist
- Core version matches a fixed release or fixed backport identified by WordPress.org.
wp core verify-checksumspasses or every difference is explained by a controlled build process.- No unknown administrators, application passwords, MU-plugins, cron entries, or executable upload files remain.
- New salts invalidate old WordPress cookie sessions; separately revoke or rotate passwords, application passwords and exposed hosting/deployment credentials, then verify that the old credentials fail.
- A staging restore of reviewed content succeeds before production cutover if rebuilding.
What This Does Not Prove
Clean checksums and a fixed version do not prove the site was never exploited. They prove only that the checked core files match the expected release at check time. Account, database, upload, plugin, theme, WAF, host, and log review are separate evidence layers.
Security, Privacy, Legal, And Recovery Boundaries
- Do not paste raw logs, salts, database passwords, user records, or exploit payloads into public tickets or articles.
- Coordinate with the host if server-level credentials, file permissions, or WAF rules are managed outside WordPress.
- Keep a clean off-host backup before destructive cleanup.
- If customer or subscriber data may have been exposed, follow your legal and notification obligations.
Exploitation and Response Context
The CISA catalog captured October 2, 2026 includes both vulnerabilities, added July 21. Its CVE-2026-63030 entry requires forensic triage and points to current BOD 26-04 guidance. Preserve the applicable record and vendor advisory with the incident. Covered agencies must follow the relevant directive requirements; catalog deadlines are not automatically a legal deadline for every private site. A KEV listing is not evidence that this particular site was compromised.
Related TechGeeks Resources
- What to Do When a Device Hits CISA KEV
- The First 60 Minutes of a Small-Office Cyber Incident
- Email Is the Root Account
