DeafNews
// 1 ZERO-DAY · 3 CVE · 4 EXPLOIT IN THE LAST 24H→
Cybersecurity EXPLOIT

WordPress Under Attack: Malicious PHP Files in /tmp in Under Five Hours

Published: Updated: By Samuel Segato 7 min read Cybersecurity
Share
WhatsApp Facebook X (Twitter) LinkedIn Reddit Telegram Email
CVE-2026-87902 is being actively exploited to write malicious files to WordPress servers. Upgrading to 7.1.2 does not remove compromises that have already occurred.

On September 22, 2026, at 17:44 UTC, less than five hours after the release of WordPress 7.1.2, the first malicious requests hit vulnerable installations. CVE-2026-87902, a core path traversal flaw with a CVSS 4.0 score of 9.2 according to the official GitHub Security Lab advisory, has already dropped malicious PHP files on exposed servers. The severity lies not only in the exploitation speed but in a technical chain that exploits common PHP configurations on shared hosting: the register_argc_argv parameter, enabled by default up to version 8.5, turns a local file inclusion into remote code execution.

Key Takeaways
  • CVE-2026-87902 is a core WordPress path traversal vulnerability; it requires no faulty plugins or themes: an unauthenticated POST with a malicious pagename parameter bypasses sanitization in get_page_template().
  • The full RCE chain requires specific conditions: a theme with a top-level page-* directory, the presence of pearcmd.php, and register_argc_argv=On; the GitHub Security Advisory lists affected themes as Twenty Twelve, Twenty Fourteen, Neve, Hestia, Sydney.
  • Malicious traffic increased tenfold in 24 hours according to Patchstack; observed filenames include wp-pear-rce-flag.php, poc87902.php, luci_<random>.php, and zeta_<random>.php, written to /tmp and /var/tmp.
  • The backport to 4.7.37 covers 24 prior branches, but WordPress no longer supports those versions: anyone running them accepts a security update with no guarantee of future maintenance.

The Mechanism: When Sanitization Arrives Late

The flaw resides in page template resolution. When WordPress processes a request, get_page_template() calls sanitize_title_with_dashes() and then urldecode() on the pagename parameter. Researcher Robert Ressl demonstrated that double-encoding the directory separator — %252f instead of %2f — passes through this sequence unscathed: wp_basename() does not interpret %2f as a slash, sanitization preserves valid octets, and the second urldecode() triggers the traversal after checks have already passed.

The result is an unauthenticated Local File Inclusion. On its own, the LFI does not execute arbitrary code: it requires a readable PHP file and a predictable path. Enter the PEAR chain. In PHP configurations with register_argc_argv=On — the default up to 8.5, including the official Docker image wordpress:php8.3-apache verified in Ressl's PoC — the file pearcmd.php interprets query arguments as PEAR commands. The attacker uses config-show to verify presence, then config-create to write an attacker-controlled PHP file to /tmp. A second request includes that file, completing the RCE.

The GitHub Security Advisory describes the conditions precisely: "An unauthenticated attacker can make get_page_template() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to RCE." The conditionality is not reassuring: many shared hosting environments, including cPanel setups with PHP prior to 8.5, satisfy all prerequisites.

The Attackers' Race: Probes, Then Weapons

Patchstack observed a classic pattern of accelerated weaponization. The first requests, at 17:44 UTC on September 22, were likely verification probes. Within 24 hours traffic increased tenfold, with a direct shift to writing persistent payloads. According to Patchstack via BleepingComputer: "The third stage swaps config-show for config-create, which pearcmd will happily use to write a file wherever it is told, with content the attacker controls."

The observed filenames — wp-pear-rce-flag.php, poc87902.php, luci_<random>.php, zeta_<random>.php — suggest a coordinated campaign rather than isolated exploits. The presence of flags with the RCE acronym in the name indicates attackers are tracking vulnerable installations, likely for subsequent access or access resale.

The NVD record assigns CVE-2026-87902 a CVSS 3.1 score of 8.1 HIGH, with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The higher 9.2 Critical score with CVSS 4.0 comes from the official WordPress GitHub Security Lab advisory. CISA added the vulnerability to the KEV catalog on September 25, 2026, with action required by September 28.

"As a courtesy, the security fix has been backported to all branches still eligible for security updates (currently back to 4.7). Note that only the latest version of WordPress is actively supported."
— WordPress, cited by TurboLab.it

The Backport Paradox: Apparent Security

WordPress's backport policy is technically correct and politically risky. Twenty-four prior branches receive the patch, from 7.0.6 down to 4.7.37. An admin running a site on 5.8 or 6.2 sees a security update available and applies it, believing they are protected. The problem is that WordPress no longer releases functional updates for those versions, does not verify compatibility with future PHP versions, and does not guarantee the backport works with third-party plugins.

IlSoftware.it warns precisely on this point: "It is not correct to say that every vulnerable WordPress installation allows RCE." The caution is necessary in the technical description but becomes dangerous in operational communication. An administrator who reads that RCE is "conditional" might delay verification, without understanding that the conditions — a theme with a page-* directory, PHP with register_argc_argv=On, pearcmd.php present — are common in the shared hosting ecosystem.

The specific attack surface for Italian or European themes among those listed is not documented. The dossier does not specify how many sites in Italy use Neve, Hestia, or Sydney, nor how many shared hosting providers keep register_argc_argv=On on PHP 8.3 or 8.4.

What to Do Now

For administrators with server access, four priority actions:

  • Immediately update to WordPress 7.1.2 if running a version from 4.7.0 to 7.1.1; verify the update completed on all sites in a multisite network.
  • Inspect /tmp, /var/tmp, and directories writable by the web process for PHP files matching observed indicators: wp-pear-rce-flag.php, poc87902.php, or patterns luci_*.php and zeta_*.php.
  • Check access logs for POST requests with pagename containing double-encoded sequences, particularly between 17:44 UTC on September 22 and the following 24 hours.
  • Check the status of register_argc_argv in php.ini: if it is On and not strictly necessary, disable it as an attack surface reduction measure, regardless of WordPress version.

The update does not delete files already written or remove any backdoors that may have been installed. Anyone who updates without verifying the filesystem assumes a risk the dossier cannot quantify, because the exact number of sites with successful RCE is not documented by the sources.

Why Five Hours Makes Manual Defense Impractical

The exploitation window, compressed between patch release and the first observed attack, makes response unrealistic for many organizations. An agency with hundreds of WordPress sites on shared hosting cannot manually update them all in five hours, especially if it must coordinate with providers controlling SSH or cPanel access. Automated updates, if configured, solve the problem for future installations but not for those already compromised.

The real question concerns the longevity of the backport. WordPress patched 4.7.37 "as a courtesy." That courtesy will not repeat indefinitely, and every site remaining on an unsupported branch accumulates technical debt that turns a security update into a migration decision. For many Italian site managers, especially on budget hosting with preconfigured PHP, code security collides with infrastructure rigidity.

Questions and Answers

My WordPress version is older than 4.7. I receive no updates. Am I at risk?
Yes. Versions prior to 4.7 receive no backport. The only documented mitigation is migration to a supported version.

I updated to 7.1.2. Do I still need to check logs?
Yes. The update fixes the vulnerability but does not remove malicious files that may have already been written. Filesystem and log verification is necessary to rule out prior compromises.

My hosting uses PHP 8.3. Is register_argc_argv dangerous even after the patch?
The register_argc_argv parameter is one of the prerequisites for the documented RCE chain. Disabling it reduces the attack surface for future vulnerabilities that might exploit similar mechanisms, even though the WordPress patch eliminates this specific vector.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references
  1. turbolab.it
  2. giapox.it
  3. ilsoftware.it
  4. nvd.nist.gov
  5. bleepingcomputer.com
  6. github.com