WordPress Core RCE under mass attack; update to 7.1.4 now

An unauthenticated remote code execution flaw in WordPress Core is being mass-scanned days after the fix shipped. Wordfence says it blocked 62,969 attacks in 24 hours targeting the bug, tracked as GHSA-4w3m-c66w-69mg (CVSS 8.1). It has no assigned CVE. The fix is in WordPress 7.1.4, released October 28. If you run WordPress, update today.

What's affected

The flaw sits in WordPress Core itself — not a plugin or theme — in versions 4.7 through 7.1.3. That's a near-decade range, so the exposed population is large. The GitHub Security Advisory describes an unauthenticated code-execution path through the staged-installer / upgrade window; Wordfence catalogs it as an "unauthenticated upgrade-window staged-installer remote code execution." Fixed version: 7.1.4.

Exploitation status

Confirmed, and opportunistic. Wordfence's threat-response lead Alex Thomas is quoted describing automated polling of installer paths such as setup-config.php, with attackers testing many staging-directory and version-name variations. SecurityWeek, citing Wordfence's parent Defiant, reports more than 77,000 related requests from over 2,000 IPs against WordPress sites — with no confirmed compromises as of October 28. That gap matters: the attempts are heavy, the staging-directory guessing is noisy, and a patched site closes the window. No public proof-of-concept has been confirmed.

Detection

Wordfence points to two concrete artifacts, both worth a grep through access logs:

• Repeated requests to setup-config.php and other installer paths.
• Activity against wp-content/upgrade, where the staged copy is unpacked.

These are behavioral indicators from Wordfence, not a published IOC set — treat unfamiliar hits on those paths as a prompt to investigate, not a confirmed breach.

Action checklist

1. Update to WordPress 7.1.4 immediately. It's a security release; test briefly, then ship.
2. Grep access logs for requests to setup-config.php and PHP files under wp-content/upgrade over the past week.
3. Check for unfamiliar admin accounts, plugins, or stray PHP files — the standard post-RCE persistence checks.
4. If you can't patch now, restrict access to installer and upgrade paths at the web-server or WAF layer as a stopgap.

Context

This is the second WordPress-ecosystem story in a tight window where the news is the exploitation wave, not the disclosure: the patch landed October 28, the mass-scanning followed within 48 hours. The same lesson that applies to every WordPress Core release holds here — the fix is public, the diff is public, and attackers reverse it faster than most sites apply it. The 4.7-to-7.1.3 range is the real exposure story: sites that auto-update are fine; sites pinned to an old major for a fragile plugin are the target set.