The rapid exploitation of CVE-2026-87902 demonstrates how little time organizations may now have between disclosure of a critical vulnerability and real-world attack activity.

WordPress released version 7.1.2 on September 22, 2026 to fix a critical unauthenticated path-traversal vulnerability in the platform’s page-template resolution logic.

Within less than five hours of the update becoming available, attackers were already probing Internet-facing WordPress installations for vulnerable systems.

By the following day, the activity had escalated significantly.

According to Patchstack, attack traffic increased approximately tenfold and moved beyond simple reconnaissance into attempts to write attacker-controlled PHP files to disk, including files capable of executing shell commands when accessed.

That transition is important.

The issue is no longer merely a theoretical vulnerability with public technical details.

Attackers are actively attempting to convert it into server-side code execution.

What is CVE-2026-87902?

CVE-2026-87902 is an unauthenticated path-traversal vulnerability in WordPress core.

The flaw affects the way WordPress resolves page templates through the get_page_template() functionality.

Under vulnerable conditions, an unauthenticated attacker can manipulate a page-related parameter so that WordPress includes a local PHP file located outside the active theme directories.

WordPress rates the issue critical, with a CVSS score of 9.2.

The basic attack path is:

unauthenticated request → path traversal → local PHP file inclusion → conditional code execution

The vulnerability affects WordPress versions from 4.7.0 through 7.1.1. WordPress backported fixes across older supported branches because of the seriousness of the flaw.

Local file inclusion does not automatically mean arbitrary code execution

An important technical distinction is that CVE-2026-87902 does not provide arbitrary remote code execution on every WordPress installation merely by sending one request.

The attacker must satisfy additional conditions.

WordPress states that the active theme must contain a top-level directory whose name begins with page-, such as:

page-templates

The targeted PHP file must also already exist locally and be readable by the web-server account.

For the known code-execution technique, attackers can attempt to abuse PHP’s pearcmd.php, particularly where PHP's:

register_argc_argv

setting is enabled.

BleepingComputer notes that this condition can affect environments including the official PHP Docker image and default cPanel configurations using PHP versions before 8.5.

The result is a vulnerability whose worst-case impact depends on the server environment, active theme, PHP configuration, and presence of useful local PHP files.

That does not make the flaw minor.

It simply means organizations need to assess actual exploitability, not merely whether WordPress is installed.

Attackers reacted to the patch almost immediately

Patchstack first observed malicious traffic at:

17:44 UTC on September 22

That was less than five hours after WordPress 7.1.2 became publicly available.

The initial requests targeted ordinary WordPress core files such as:

wp-links-opml.php

wp-includes/functions.php

wp-cron.php

Those files did not provide attacker-controlled code execution.

Instead, the requests appeared designed to determine whether a target was vulnerable to the file-inclusion primitive.

This suggests attackers were using the vulnerability first as a reconnaissance mechanism.

Once a server responded in a way that confirmed the inclusion worked, the attacker could potentially return with a more dangerous payload.

The exploitation quickly progressed to file creation

Within roughly a day, the activity changed.

Patchstack and BleepingComputer observed attackers using the vulnerable path to reach functionality capable of creating files on disk.

Some payloads simply wrote marker files confirming that the server was exploitable.

Others wrote PHP containing a short command-execution construct.

Observed filenames included:

wp-pear-rce-flag.php

poc87902.php

luci_<random>.php

zeta_<random>.php

The files were written into locations including:

/tmp

and:

/var/tmp

This represents a major escalation from vulnerability scanning.

Once attacker-controlled PHP exists on the server and can be reached through the web stack or another execution path, the attacker may be able to execute operating-system commands using the privileges of the web-server process.

Why web-server-level command execution matters

A web-server account does not necessarily have root privileges.

However, code execution under that account can still create significant risk.

Depending on configuration and permissions, an attacker may potentially:

  • read WordPress configuration files;
  • access database credentials;
  • modify website content;
  • create or modify administrator accounts;
  • deploy additional backdoors;
  • tamper with plugins or themes;
  • steal customer or user data;
  • access environment variables;
  • pivot toward other services reachable from the web server; or
  • establish more durable persistence.

WordPress configuration files commonly contain database credentials and authentication secrets.

Therefore, even code execution under a restricted web-server identity can become the starting point for broader compromise.

The speed of weaponization is one of the biggest lessons

The timeline is arguably as important as the vulnerability itself.

The vulnerability was patched on September 22.

Attackers began probing it within hours.

By September 23, the activity had moved into attempts to create executable PHP payloads.

That is an extremely short defender window.

The likely reason is straightforward: once the patch became public, attackers could compare the vulnerable and fixed code, identify the security-relevant change, and build requests targeting the missing validation.

Patchstack specifically noted that the early payloads appeared consistent with attackers working from the patch diff.

This is a classic example of patch diffing becoming a rapid exploitation technique.

The vendor patch protects updated users.

At the same time, it can unintentionally provide attackers with a roadmap to vulnerable installations that have not yet updated.

This is why delayed patching has become increasingly dangerous

Many organizations still treat WordPress updates as routine maintenance to be scheduled later in the week or month.

That approach is increasingly difficult to justify for critical Internet-facing vulnerabilities.

A publicly reachable WordPress installation is easy to discover at scale.

Attackers can automate requests across thousands or millions of sites almost immediately after technical details become available.

For CVE-2026-87902, the attack does not require:

  • a WordPress account;
  • administrator interaction; or
  • successful phishing.

The attacker can simply send requests directly to the website.

This dramatically lowers the cost of mass exploitation.

Organizations should update immediately

The primary remediation is to install the patched WordPress release corresponding to the branch in use.

WordPress 7.1.x should be updated to:

7.1.2

Other patched branches include:

  • 7.0.6
  • 6.9.9
  • 6.8.10
  • 6.7.9
  • 6.6.9
  • 6.5.12

and additional backports extending down to WordPress 4.7.37.

WordPress explicitly recommends updating immediately.

Automatic background updates may already have applied the security release on some sites, but administrators should verify the installed version rather than assuming the process completed successfully.

WordPress 4.6 and earlier will not receive this fix

WordPress notes that releases before 4.7 are no longer receiving the patch.

Any Internet-facing site still running WordPress 4.6 or earlier therefore has a much larger problem than this individual CVE.

Such deployments should be treated as unsupported legacy systems and upgraded or replaced rather than attempting to operate indefinitely around a growing set of unfixed vulnerabilities.

Administrators should not stop at patching

Because exploitation began almost immediately after the vulnerability became public, sites that were exposed before patching should also be investigated.

The absence of visible website defacement does not prove the site was not compromised.

Administrators should review web-server logs for suspicious requests involving:

  • double-encoded traversal sequences;
  • unusual pagename values;
  • requests containing both pagename and page_id;
  • unexpected responses from core PHP files; or
  • repeated requests targeting page-template handling.

Patchstack specifically observed payloads involving double-encoded traversal sequences in the pagename parameter.

File-system inspection is equally important

Security teams should search for unexpected PHP files in writable directories.

Particular attention should be paid to:

/tmp

/var/tmp

WordPress upload directories, theme directories, plugin directories, and other web-server-writable locations.

Observed names such as:

wp-pear-rce-flag.php

and:

poc87902.php

are useful indicators, but attackers can change filenames trivially.

A stronger hunting strategy is to identify recently created PHP files in locations where PHP files normally should not appear.

Review database and WordPress administrator activity

If command execution is suspected, defenders should also examine whether attackers subsequently used local credentials to move deeper into WordPress.

Useful checks include:

  • newly created administrator users;
  • changed administrator email addresses;
  • unexpected password resets;
  • unfamiliar plugins;
  • modified themes;
  • newly enabled plugins;
  • unexpected cron entries;
  • changes to wp-config.php;
  • suspicious database modifications; and
  • unfamiliar outbound network connections from the web server.

A web shell is often only the first stage.

Attackers typically establish additional persistence once they obtain reliable execution.

Rotate credentials after confirmed compromise

If evidence indicates that arbitrary commands executed on the server, organizations should consider sensitive secrets accessible to the web-server process potentially exposed.

Depending on the environment, this may require rotation of:

  • WordPress administrator credentials;
  • database passwords;
  • hosting-panel credentials;
  • API keys;
  • deployment credentials;
  • SMTP passwords;
  • WordPress authentication salts; and
  • other secrets stored in environment variables or local configuration files.

Simply deleting the attacker’s PHP file does not revoke credentials already stolen from the server.

Web application firewalls can help, but they are not the fix

Patchstack deployed a mitigation rule for protected customers while the security release became available.

WAF or virtual-patching controls can provide valuable temporary protection, particularly for environments where immediate updates are operationally difficult.

However, they should not be treated as substitutes for updating WordPress core.

Attackers can modify payload encoding and request structure, while the underlying vulnerability remains present until the code itself is fixed.

Theme configuration affects exploitability

Organizations should also check whether the active parent or child theme contains a top-level directory beginning with:

page-

That is one of the conditions required for the known exploitation path.

Patchstack also recommends checking whether PHP's:

register_argc_argv

setting is enabled, because this affects the known pearcmd.php code-execution technique.

These checks are useful for risk assessment.

They are not substitutes for patching.

A configuration that happens not to satisfy the currently documented exploit chain may still become exploitable through another local PHP file or technique.

WordPress core vulnerabilities have unusually broad consequences

WordPress powers an enormous number of websites.

A core vulnerability is therefore fundamentally different from a flaw in a niche plugin with a few thousand installations.

Attackers can scan huge parts of the public Internet for WordPress fingerprints and attempt the same exploit automatically.

Even if only a subset of installations satisfies the full RCE preconditions, that subset may still represent a large number of exploitable sites.

This is why critical WordPress core vulnerabilities tend to attract attacker interest almost immediately.

The vulnerability also illustrates the risk of local file inclusion

Local file inclusion can sometimes be dismissed as less severe than direct arbitrary file upload or command injection.

CVE-2026-87902 shows why that assumption can be dangerous.

If an attacker can force the application to include a strategically useful local PHP file, existing server functionality can become part of the exploit chain.

The attacker does not necessarily need to upload their own malicious executable first.

They can weaponize code that is already present on the server.

This is another example of how seemingly separate configuration decisions can combine into a much more serious exploit.

The broader cybersecurity lesson

CVE-2026-87902 demonstrates three increasingly important realities of vulnerability management.

First:

Internet-facing vulnerabilities are weaponized extremely quickly.

In this case, attackers began probing less than five hours after the fix was released.

Second:

Attackers increasingly use patch diffs as exploit-development guides.

Publishing the fix inevitably reveals information about what was wrong.

Third:

Patching closes the vulnerability, but it does not establish that the system was never compromised.

Once exploitation activity has already begun, remediation needs to include both:

patching + compromise assessment

The timeline here is brutally simple:

September 22: patch released → within five hours: probing begins → September 23: attack volume increases approximately tenfold → attackers start writing PHP capable of shell-command execution.

That leaves very little room for organizations whose critical-update process still begins with “we’ll discuss it at the next maintenance meeting.”

For Internet-facing WordPress sites, the practical lesson is clear:

When a critical unauthenticated core vulnerability is disclosed, update immediately, then investigate the period before the update.

The attackers are no longer waiting politely for defenders to finish reading the advisory.

Threat actors have moved from probing WordPress sites vulnerable to CVE-2026-87902 to exploiting the flaw to write files to disk that execute shell commands when accessed. [...]

Source: Hackers start exploiting critical WordPress flaw for code execution via Bleeping Computer — published 23 Sep 2026.