CISA Confirms Exploitation of WordPress Core Upgrade Flaw

CISA confirms exploitation of a WordPress Core upgrade flaw. Learn which versions contain fixes and what administrators should check for signs of compromise.

Written By
Michelle Lojo
Michelle Lojo
Nov 4, 2026
3 minute read
Close-up of a laptop screen displaying the WordPress.com website with its logo and Products, Features, and Resources navigation menus.

WordPress administrators should verify Core updates and check for signs of compromise following exploitation of an upgrade-process flaw. Image: Stephen Phillips/Unsplash.

eSecurity Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

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.

Advertisement

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.

Michelle Lojo

Michelle Lojo is an editor with eight years of experience in journalism. She covers the developments, companies, and emerging trends shaping enterprise technology. Her editorial work focuses on clear, well-researched reporting that helps business and IT leaders understand a rapidly changing technology landscape.

eSecurity Planet Logo

eSecurity Planet is a leading resource for IT professionals at large enterprises who are actively researching cybersecurity vendors and latest trends. eSecurity Planet focuses on providing instruction for how to approach common security challenges, as well as informational deep-dives about advanced cybersecurity topics.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.