U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds WordPress flaw to its Known Exploited Vulnerabilities catalog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a WordPress flaw, tracked as CVE-2026-119977 (CVSS score of 8.1), to its Known Exploited Vulnerabilities (KEV) catalog.

CVE-2026-119977 is a high-severity remote code execution vulnerability affecting WordPress versions 4.7 through 7.1.3. It stems from predictable, web-accessible staging directories used during core updates.

Unauthenticated attackers could exploit a race condition to execute malicious code on the server while an update is in progress, potentially compromising the website. WordPress addressed the flaw in version 7.1.4.

Threat actors began scanning for CVE-2026-119977 shortly after WordPress released the security update. Wordfence recorded more than 18,500 requests targeting vulnerable staging installer paths within the first 21 hours. However, these figures document exploitation attempts, not confirmed successful compromises.

“Wordfence telemetry shows that threat actors are already actively attempting to exploit the vulnerability. The first match for our new firewall rule arrived nine minutes after deployment. During the first 21 hours, we recorded more than 18,500 requests targeting staged setup-config.php installer paths.” reads the report published by Wordfence.

“Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window. Other sources tested many staging-directory and version-name variations.”

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to fix the flaw by November 6, 2026.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CVE-2026-119977)

U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds WordPress flaw to its Known Exploited Vulnerabilities catalog.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a WordPress Core flaw, tracked as CVE-2026-87902 (CVSS score of 9.2), to its Known Exploited Vulnerabilities (KEV) catalog.

CVE-2026-87902 allows an unauthenticated attacker to make the get_page_template() function include a readable local PHP file outside the active theme directories. Under specific server and theme conditions, the flaw can lead to remote code execution. The vulnerability is being actively exploited, with attackers using pearcmd.php to write malicious PHP files and execute code.

This week, WordPress released version 7.1.2 to address this flaw. It stems from how the CMS resolves page templates, with a real path to remote code execution.

The bug affected every version back to 4.7.0. That’s nearly a decade of releases, and nobody needs an account to trigger it. Robert Ressl gets credit for reporting it.

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to fix the flaw by September 24, 2026.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, CISA)

WordPress 7.1.2 fixes an unauthenticated file inclusion bug active since version 4.7, patchable but exploitable into remote code execution.

WordPress 7.1.2 shipped on September 22 address an unauthenticated local file inclusion, tracked as CVE-2026-87902 (CVSS score of 9.2), which stems of how the CMS resolves page templates, with a real path to remote code execution.

The bugs affected every version back to 4.7.0. That’s nearly a decade of releases, and nobody needs an account to trigger it. Robert Ressl gets credit for reporting it.

The flaw resides in get_page_template(), the function WordPress uses to choose which template should load a page. WordPress creates a list of possible template filenames, and one of them comes directly from the pagename value in the URL without any proper validation.

The problem becomes clearer when you look at the code around it. Just above the vulnerable line, WordPress uses validate_file() to check another filename and block directory traversal. But the filename built from pagename completely skips that security check, even though it sits only three lines below the protected code.

Getting from that gap to something dangerous takes a bit of luck, but not much. The filename gets built as page-{$pagename}.php, so the attacker needs a theme with a folder starting with page-, which plenty of legacy and third-party themes still have. A urldecode() call earlier in the process is what turns an otherwise harmless-looking string into a working traversal path.

Reading an arbitrary file isn’t code execution on its own. It only runs whatever that file already does. The well-known trick is pulling in PEAR’s pearcmd.php, and that only fires if PHP has register_argc_argv switched on, a setting that happens to be the default in the official PHP Docker images and in cPanel setups running anything older than PHP 8.5.

“Including a local .php file is not by itself code execution of the attacker’s choosing. It runs whatever that file does. Getting from there to arbitrary code needs a readable .php file on the server that behaves usefully when included, and the well-known candidate is PEAR’s pearcmd.php, which only becomes useful when PHP is running with register_argc_argv enabled.” reads the report published by the cybersecurity firm PatchStack. “That setting is on by default in the official PHP Docker images and in cPanel environments on PHP below 8.5, so “unusual configuration” undersells how common it is.

So the honest framing is a conditional chain: unauthenticated file inclusion always, code execution when the host happens to line up.”

So the honest way to describe this bug is a chain, not a single click. File inclusion works everywhere, no exceptions. Code execution only fires when the server’s setup happens to line up, and a lot of servers do.

WordPress’s fix does two things, and the second one is the more telling of the two. The obvious patch runs the missing validate_file() check on the pagename branch, closing exactly the hole that got reported. The less obvious one adds a new function, _wp_is_template_path_allowed(), that every resolved template path now has to pass, no matter which code path produced it.

The second change is also worth noting. A one-line fix would have addressed the reported bug, but WordPress instead added a broader check across the template system. That suggests the security team wanted to make sure there were no other ways to reach the same problem.

If you cannot patch right away, two quick checks can help you understand your exposure. First, see if your active theme contains a folder starting with page-. Then check whether PHP has register_argc_argv enabled. Neither is a fix, but both can help show whether your site could be affected.

Updating is simple enough that there’s no good excuse left. It’s sitting in the Dashboard under Updates, or on WordPress.org directly, and every supported branch back to 4.7 already has its own backported fix waiting.

“Treat it as critical unless you have checked your own stack and know otherwise.” concludes Patchstack.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, WordPress)