CVE-2026-119977: The WordPress Flaw That Is Exploited While You Update

During a full-package upgrade, WordPress unpacks the new release into a staging location under wp-content/upgrade before moving files into place. According to the CVE record, which Wordfence published, those staging paths are predictable and web-accessible, and that lets an unauthenticated attacker execute code on the server during the upgrade window. WordPress's own release post describes it as a weakness in the upgrade process that can lead to remote code execution during the window.

The window is short, often seconds, which is why the flaw carries a CVSS 3.1 score of 8.1 with high attack complexity and not a higher one. A narrow window does not make it safe to ignore. Automated polling exists precisely to catch narrow windows, and a slow host or a large update stretches them. No login and no user interaction are required.

Exploitation is confirmed by its presence in CISA's catalog. Published volume figures vary widely because vendors are measuring different things over different periods. Wordfence, in an update quoted by BleepingComputer, reported blocking 13,095 attacks targeting the flaw in 24 hours. Other reports citing vendor telemetry give considerably higher daily counts.

Keep those figures in proportion. Blocked requests are attempts, not successful compromises, and as of this writing we have not seen a named, confirmed victim or confirmed ransomware use. The attempts are still relevant: they tell you that mass scanning is already happening, and that a small site is not too small to be reached.

Move to WordPress 7.1.4. WordPress says sites that support automatic background updates will begin updating automatically, and that fixes are being backported to older branches back through 4.7. Its post, last modified October 29, describes those backports as in progress and shipping as they become ready. Only the most recent version is actively supported, so an older branch should be a short stop and not a destination.

Do not assume that an automatic update happened. Background updates can fail quietly, and they are commonly switched off on purpose in setups with version-controlled deployments, Composer-managed core, read-only file systems, or container images that pin a WordPress version. In those setups nothing changes until someone ships a new build. If your host manages updates for you, get written confirmation of the running version.

If you must wait, denying web access to wp-content/upgrade at the web server is a reasonable temporary measure that some responders recommend. Test it first, make sure the update still completes, and keep it in place only as long as you need it. If you rely on a plugin-based firewall, Wordfence has reportedly warned that direct requests to staged PHP files may bypass it unless the firewall loads early, so do not treat it as sufficient on its own.

Finishing the update closes the door, but it does not tell you whether someone already came through it. An attacker who got in before the upgrade can keep access afterward through a dropped file or a new administrator account. This check matters most for any site that updated, manually or automatically, while still on a vulnerable build.

If you find something you cannot explain, stop treating it as routine maintenance. Isolate the host, preserve logs before anything rotates them away, and rotate every secret the PHP process could read, which includes database credentials, API keys, and salts in wp-config.php. Restoring from a clean backup is usually more reliable than trying to clean a live site by hand.

CVE-2026-87902, disclosed September 22, is a different flaw in page-template resolution. It can let an unauthenticated attacker include a chosen local PHP file from outside the active theme's directories, and it can lead to code execution when certain conditions on the server and in the active theme are met. Fixes shipped in 7.1.2, 7.0.6, 6.9.9, and 6.8.10.

The Hacker News reported a CVSS score of 9.2 and a first recorded attack attempt on the day of release. CISA added it to the exploited list on September 25. The preconditions limited how many sites were realistically at risk, and one security firm's CEO expected relatively few real compromises. The speed is the point: the gap between a public fix and attackers testing it was measured in hours, so a monthly maintenance window would have started well behind them.

WordPress is often where AI-assisted building meets an older stack. Founders generate custom themes and plugins with coding assistants, use WordPress as a headless content source behind a modern front end, or run a store on it because it was the fastest route to revenue. These setups can work very well. They also tend to contain custom code nobody has reviewed, automatic updates someone turned off to stop a generated theme from breaking, and a staging copy nobody remembers.

That combination is the actual risk. Core bugs like these are not caused by AI-generated code, and a careful team could still be caught by one. But a team that knows what it runs, keeps updates flowing, and can test a generated plugin against a new release can respond in an afternoon. A site where updating feels dangerous tends to stay on old versions, which is exactly where these attacks land.

If an update scare would send you hunting for whoever built the site, it is worth fixing that before the next advisory. An experienced engineer can review custom code, separate content from deployment, set up tested updates and backups you have actually restored, and put a person on the hook for reading advisories. We do this as a production hardening engagement, and through retainers where ongoing ownership is the need.