Critical WordPress Core Vulnerabilities: How to Secure Your Site Against Active Exploits

The affected releases are WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. This is not a theoretical exposure: Patchstack, Hexastrike, and WatchTowr have reportedly observed exploitation in the wild.

For WordPress operators, the priority is version state, not speculation about attack volume. A site still on an affected release must be treated as exposed until the core update is verified and the environment is reviewed.

The exposure is in WordPress core

TechCrunch reports that the two critical flaws can be combined to give an attacker full remote control of a vulnerable site. One of them was reported by Adam Kues of Searchlight Cyber and named WP2Shell.

WordPress enabled forced updates where possible and urged administrators to update immediately. That does not establish that every installation has received the fix. Managed hosting configuration, disabled auto-updates, filesystem permissions, custom deployment workflows, and stalled update jobs can all leave a site on an affected version.

The raw installed version is the first control point. Do not infer patch status from a successful dashboard login, a working storefront, or the absence of visible defacement. Those are not integrity checks.

Verify the patch before reviewing symptoms

Run this sequence across every production, staging, and forgotten subdomain installation:

1. Confirm the installed WordPress core version. Versions 6.9.0–6.9.4 and 7.0.0–7.0.1 are identified by TechCrunch as vulnerable. Record the result per host and per site, including multisite networks.

2. Apply the available core update immediately. Complete the update through the site’s established change process, then confirm that the version persisted after cache clears, container restarts, or deployment synchronization.

3. Inspect access and server logs for unexpected activity. The reported impact is remote takeover, so baseline symptoms such as a normal homepage response or stable TTFB do not clear the host. Review logs around the period in which the site remained unpatched and preserve them before rotation.

4. Check for unauthorized changes. Prioritize WordPress core files, administrator accounts, active plugins and themes, scheduled tasks, and server-side configuration. A patched site may still require incident response if compromise occurred before remediation.

For WooCommerce stores, this is an operational risk as well as a core-maintenance issue. A compromised site can be used for malware distribution, phishing, or botnet activity, according to the reporting. Treat checkout availability as separate from platform integrity.

What to monitor next

The scale remains uncertain. TechCrunch notes that official WordPress statistics showed more than 400 million sites on affected versions, while a consultant’s sample-based estimate suggested fewer than 15% might remain vulnerable; neither number confirms the current count of exposed installations.

The actionable baseline is narrower:

• WordPress core is outside 6.9.0–6.9.4 and 7.0.0–7.0.1.
• The successful update is verified on the live filesystem and in the running application.
• Logs covering the unpatched interval are retained and reviewed.
• File, account, plugin, theme, and task changes are accounted for.
• Any unexplained modification is handled as a possible compromise, not dismissed as update noise.

The patch closes the known vulnerable state. It does not retroactively sanitize a site that was already taken over.