Apply WordPress 7.0.3, or the equivalent patched minor release for your supported branch such as 6.9.6, 6.8.7, or 6.7.6, without delay. This is the only fix for the underlying flaw; every other measure reduces blast radius without closing the vulnerability. Verify the running version directly through the dashboard, hosting control panel, WP-CLI, or asset inventory rather than assuming an automatic update policy has applied.

Build or refresh a complete inventory of WordPress installations across the estate, including instances outside centralized patch management. Departmental, laboratory, research group, campaign, and course sites are the highest-risk population precisely because they are internet-facing and self-administered. Record the Core version for each so remediation can be tracked to completion.

Installations running WordPress 4.6 or earlier are end of life and will receive no patch for CVE-2026-64638. Any such instance must be migrated onto a supported and patched branch, isolated from public reachability, or decommissioned outright. Treat continued public exposure of an unsupported Core version as an accepted risk requiring explicit sign-off.

Defining DISALLOW_FILE_MODS in wp-config.php breaks the plugin upload stage of the chain and is sound configuration on any installation where the plugin lifecycle is managed by deployment. Where feasible, additionally prevent direct PHP execution from inactive plugin directories, since the demonstrated chain reaches code execution without ever activating the uploaded plugin.

Accounts limited to content publication should hold the Editor role rather than Administrator. The escalation chain depends specifically on the default unfiltered_html and upload_plugins capabilities held by single-site Administrators, so narrowing that population directly narrows the set of users whose compromised browser session can be converted into server-side code execution.