WordPress Core Under Active Exploitation: Verify the Fix and Rule Out Compromise

When WordPress core is actively exploited, the dashboard update button is necessary but not sufficient. You need to prove the fixed branch is installed, verify core integrity, inspect the places attackers commonly persist, and decide whether a clean rebuild is safer than continuing on a server that may already be dirty.

Reader question: After updating WordPress, how do I prove the site was not already compromised? Practical answer: You cannot prove absence of compromise with one dashboard screen. You collect enough evidence: fixed version, clean checksums, expected users, clean plugins/themes/MU-plugins, known cron, clean uploads, reviewed logs, rotated salts and credentials, and a rebuild plan if the evidence is incomplete.

Patch

Verify the actual branch and fixed release, including supported backports where used.

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.

The Short Version

• Confirm WordPress is on a fixed branch, not merely that the dashboard says an update ran.
• Run core checksum verification and inspect users, plugins, themes, MU-plugins, cron, uploads, and database options.
• Rotate salts, admin passwords, application passwords, hosting passwords, and deployment credentials when compromise is plausible.
• If logs are missing or malicious files are found, rebuild from clean core and reviewed content rather than trusting an in-place cleanup.

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

WordPress security releases may include backports for older supported branches. Your first job is to identify the branch and fixed version actually running on the server, not the version you expected auto-update to install.

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.

wp core version
wp core check-update
wp core verify-checksums
wp plugin list
wp theme list
wp user list --role=administrator

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-checksums passes or every difference is explained by a controlled build process.
• No unknown administrators, application passwords, MU-plugins, cron entries, or executable upload files remain.
• Old salts and credentials no longer work.
• 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.

Publication-Day Rechecks

• Reopen the WordPress release post before publication.
• Confirm CISA KEV status and due-date language directly in the catalog.
• Check NVD/CVE entries for updated affected-version wording.

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

References

• WordPress 7.0.2 Release
• CISA Known Exploited Vulnerabilities Catalog
• CVE-2026-63030 Record
• NVD CVE-2026-63030

Final Operational Standard

The WordPress standard is evidence, not vibes: fixed version, clean integrity checks, reviewed persistence paths, rotated credentials, and a clean rebuild path when the evidence does not support trust.