WordPress RCE wave is three separate flaws in PHP, core and ACF Extended PRO

Not one bug, but three

The WordPress vulnerability circulating this week is really three distinct remote-code-execution problems, each arriving through a different component with its own maintainer and release channel, according to an analysis by the Teamvoy team on dev.to. The PHP engine, WordPress core and a commercial plugin each carry a share of the risk, so a dashboard showing an up-to-date WordPress addresses only about a third of the problem.

Core carries the actively exploited flaw

CVE-2026-119977 affects WordPress 4.7.0 through 7.1.3 and was fixed in 7.1.4, released on 28 October, with backports reaching every branch back to 4.7.39. Sites on 4.6 or earlier receive nothing and need a full upgrade rather than a patch. CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 3 November, giving US federal agencies until 6 November to remediate.

The bug itself is unusual: a time-of-check-to-time-of-use race in the full-package core upgrade process. The staging directory used during an upgrade had a predictable, web-accessible name derived from the version string, so an unauthenticated attacker who landed inside the window could execute code — the act of upgrading was what opened the door. Version 7.1.4 randomises the staging directory with a cryptographically unpredictable suffix, retains an index.php guard file, and stops staged configuration data from being promoted unsafely.

Attackers did not wait. Wordfence shipped a blocking rule roughly three hours after the release announcement, and the first request matching it arrived nine minutes later. Telemetry cited in the analysis shows more than 13,000 blocked attempts against this CVE within a single 24-hour window.

The PHP runtime belongs to a different owner

The two PHP CVEs, nicknamed php2shell, affect 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12, with fixes in the PHP releases of 21 October. CVE-2026-109618 concerns request-memory handling after out-of-memory errors; CVE-2026-109619 concerns stale global state surviving into later requests. Because the flaw sits in the engine, a site with fully patched core and plugins remains exploitable on a vulnerable runtime.

Two cautions come from the write-up. First, php -v reports the CLI binary, which can differ from the build the web server actually serves, so operators should verify the served version and ask hosts to map their package build to both CVE numbers, since distributions backport quietly. Second, PHP's advisory names session upload progress as an attack path for CVE-2026-109619 and recommends turning it off; WordPress core does not use the feature. On PHP 8.1 or older, which has no official fixed release, that setting shuts the confirmed session-based routes, though it does not fix everything on its own.

ACF Extended PRO: aim for 0.9.2.8

The third layer is CVE-2026-120534, an unrestricted upload of a file with a dangerous type (CWE-434) scoring 9.8 on CVSS, affecting ACF Extended PRO through 0.9.2.6. Patchstack records 0.9.2.7 as the patched version for that CVE, but it separately tracks two more issues in the 0.9.2.4 to 0.9.2.7 range — unauthenticated arbitrary shortcode execution and contributor-level XSS — both fixed in 0.9.2.8. Operators touching the plugin should therefore go to 0.9.2.8 or later rather than stopping at the version that one CVE entry lists as fixed. The analysis also notes that disabled plugins leave their files on disk, so inventories should cover present-but-inactive installs too.

Patching is not proof

For remediation, Teamvoy recommends freezing unrelated changes, inventorying all three layers across every environment, preserving logs and deployment records before retention windows close over them, taking a tested restorable backup, and rehearsing in staging that mirrors production before patching each exposed layer. Order can follow exposure: a host that can patch PHP without application changes is an early, low-risk win.

The write-up closes with a warning that patches say nothing about the past. With core exploited in the wild since 28 October, updating quickly and never having been hit are separate questions. Post-patch triage should compare logs, admin accounts, scheduled tasks, modified PHP files, outbound connections and file-integrity results against a known-good release, remembering that scanners miss deleted artefacts and activity outside their view.

Why it matters

The takeaway from the analysis is about ownership rather than blanket updating. The runtime, core and plugin inventory each belong to different owners, and until all three have reported, an incident response is simply unfinished. The Wordfence figures show attackers arrive within minutes of a release, which makes partial answers expensive. And the ACF Extended case carries a wider lesson: patching to the version named in one CVE record can leave adjacent flaws in the same code range unfixed, so version targets deserve as much scrutiny as the CVE list itself.