The WordPress PHP Vulnerability Is Three CVEs With Three Owners

The WordPress PHP vulnerability going round this week is actually three separate remote-code-execution risks, reaching WordPress operators through three different components with three different owners and three different release channels. A "WordPress is updated" screenshot answers roughly a third of the question.

Start with Core, because the clock is real

CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue on 3 November, with a federal remediation deadline of 6 November. It is being exploited now.

The mechanics are worth understanding, because they're unusual: it's a time-of-check-to-time-of-use race in the full-package core upgrade process. The staging directory had a predictable, web-accessible name derived from the version string, so an unauthenticated attacker who hits the window during an upgrade can execute code. The update itself was the exposed moment.

7.1.4 fixes it by randomising the staging directory with a cryptographically unpredictable suffix, keeping and recreating an index.php guard, and preventing unsafe promotion of staged configuration data.

On the speed of exploitation: Wordfence deployed a blocking rule roughly three hours after the release announcement, and the first request matching it arrived nine minutes later. Recent telemetry has it blocking over 13,000 attacks against this CVE in a 24-hour window.

Every branch from 4.7 up got a backport. 4.6 and earlier get nothing — those sites need an upgrade, not a patch.

The PHP layer is a different owner

php2shell sits in the PHP engine, below the application. WordPress Core and every plugin can be fully current and the site is still exploitable on a vulnerable runtime. CVE-2026-109618 concerns request-memory handling after out-of-memory errors; CVE-2026-109619 concerns stale global state surviving into later requests.

Two practical notes:

• php -v reports the CLI binary, which can differ from the build your web SAPI serves. Check the served version, and ask your host to map its package build to both CVE numbers — a branch label doesn't settle patch status when distributions backport.
• PHP's advisory names session upload progress as an attack path for CVE-2026-109619 and suggests turning it off, and keeping it off if you don't use it. WordPress Core doesn't use the feature. For anything still on 8.1 or older, where there's no official release at all, that setting blocks the confirmed session paths without being a complete fix. ## The plugin layer, and a correction worth making

CVE-2026-120534 is an unrestricted upload of a file with a dangerous type (CWE-434), CVSS 9.8, affecting ACF Extended PRO through 0.9.2.6.

Patchstack lists 0.9.2.7 as the patched version for that CVE. But Patchstack separately records two further issues in the 0.9.2.4–0.9.2.7 range — an unauthenticated arbitrary shortcode execution and a contributor-level XSS — both patched in 0.9.2.8. If you're touching this plugin anyway, go to 0.9.2.8 or later rather than stopping at the version one CVE record names.

Check whether the plugin is installed, active, or present-but-disabled. Deactivated plugin files still sit on disk.

Patch sequence that doesn't become an outage

Urgency should shorten decision time, not remove recovery controls.

1. Freeze unrelated changes. Keep the security release small enough to diagnose and reverse.
2. Inventory all three layers across every environment — PHP build, Core version, plugins, themes, custom code, hosting model.
3. Preserve evidence first if compromise is plausible. Save logs and deployment records before retention windows or routine updates overwrite them. This step is irreversible if you skip it.
4. Take a restorable backup — database, uploads, configuration, deployment artifacts — and test the restore path.
5. Rehearse in staging matching production PHP settings, extensions, and web server behaviour.
6. Test the business paths: login, forms, publishing, scheduled jobs, email, payments, API integrations, admin workflows.
7. Patch each exposed layer, then run production smoke tests.
8. Retain the change evidence — versions, timestamps, approvals, test results, rollback decisions. Order depends on exposure and control. If your host can patch PHP without application changes, take that reduction early and document it. An exposed plugin may need isolating before a wider upgrade.

Patching is not proof of a clean site

A patch closes a known path. It doesn't demonstrate nobody used it earlier, and with Core under active exploitation since 28 October, "we updated" and "we were never compromised" are different claims.

Post-patch triage, compared against a known-good baseline:

• Web, PHP, application, WAF/CDN, authentication, and hosting control-plane logs.
• Unexpected administrator accounts, API credentials, scheduled tasks, configuration changes.
• Modified PHP files, unfamiliar plugins or themes, files added to writable directories.
• Outbound connections, process activity, redirects, traffic that differs from baseline.
• Deployment history and file-integrity results against a known-good release.
• Whether your logs even cover the vulnerable period, and whether clocks align across systems. Absence of indicators isn't absence of compromise. Scanners miss deleted artefacts and anything outside their visibility.

The useful mental model for all of this: the fastest response isn't one blanket update, it's accurate ownership. Someone owns the runtime, someone owns Core, someone owns the plugin inventory, and until all three have answered, the response is incomplete.

Full write-up with the version tables, evidence checklist, and sources: teamvoy.com/blog/wordpress-php-vulnerability-2026

More engineering writing from the Teamvoy team at teamvoy.com/blog.