A brief window during some WordPress Core upgrades can let attackers execute code on a website’s server without logging in.
CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on Nov. 3, according to the Canadian Centre for Cyber Security. The flaw affects unpatched releases across WordPress branches from 4.7 through 7.1.3; older branches with the corresponding backported fix are protected against it.
Administrators need to complete the update safely and check whether attackers accessed their sites before protection was in place.
How the upgrade window exposes WordPress sites
The high-severity flaw, rated CVSS 8.1, involves predictable, web-accessible staging paths created during full-package Core upgrades. Attackers who reach the temporary installer files at the right moment could execute code on the server. Wordfence says the window typically lasted only seconds in lab testing, but attackers repeatedly polled the paths to catch it.
“What stands out is where this flaw lives: inside the upgrade process, so the exposure opens during the same maintenance window teams rely on to make them safer,” said Joe Brinkley, director of offensive security research and community at Cobalt.
The vulnerability is separate from the Bricksforge plugin flaw that exposed WordPress sites to unauthenticated code execution. Updating a plugin does not fix Core, and updating Core does not resolve every vulnerable component.
Which WordPress versions contain the fix?
WordPress released version 7.1.4 on Oct. 28 and recommends updating immediately. The project credits Umut Bayram with reporting the upgrade flaw.
Fixes also reached older branches. Wordfence lists patched releases including 7.0.8, 6.9.11, 6.8.12, and 4.7.39. Administrators should verify their branch’s fixed version rather than assume every release below 7.1.4 remains vulnerable. WordPress says only its most recent version is actively supported.
Organizations should prioritize this fix because CISA has identified the vulnerability as exploited in the wild.
What administrators should do before closing the incident
Start by identifying each WordPress installation, its Core version, and the person or provider responsible for updates. Confirm that automatic updates have actually completed.
Because exposure occurs during an upgrade, ask the server or hosting team to restrict public access to temporary upgrade directories where feasible. Coordinate that protection with the update process without delaying the security fix.
Keep dependencies in scope: the separate WordPress HEIC image-processing attack shows why updating the CMS alone does not establish that the hosting stack is secure.
Bayram, a security researcher at Picus Security, said defenders should test protections when their exposure changes.
“That’s why validation can’t wait for the next scheduled test anymore. It should start when something changes,” he said.
As an investigation step, compare recent upgrade timestamps with web logs for requests to staged installer files beneath wp-content/upgrade, particularly setup-config.php. Investigate unfamiliar administrator accounts, unexpected PHP files, configuration changes, and unusual outbound connections. These are investigation leads, and a suspicious request alone does not prove compromise.
If evidence suggests an intrusion, preserve logs and involve incident responders before removing suspicious files. Assess whether attackers could access application credentials or secrets and whether those need replacement.
The distinction between patch management and vulnerability management matters here: a successful update closes the vulnerable behavior, but does not prove an attacker’s access has been removed. Before closing the response, record the installed fix, investigation findings, and any gaps in available evidence. Managed hosting customers should request those details from their provider.
Read more: Explore what security teams should verify after Black October’s PHP patches, including earlier attack attempts, configuration risks, and whether fixes are active across exposed applications.





