WordPress fixes critical flaw that loads PHP without authentication

WordPress released version 7.1.2 on September 22 to fix CVE 2026 87902. The flaw received a CVSS score of 9.2 in the official advisory. The issue lies in the platform's core, not in a plugin or theme.

The vulnerability allows an unauthenticated attacker to manipulate page template resolution. As a result, the system attempts to include a local PHP file chosen by the attacker.

In certain combinations of theme and server, the scenario escalates to remote code execution. Therefore, the update became an immediate priority.

WordPress failed to validate the template path

The affected mechanism decides which PHP file renders each page. This logic needs to accommodate varied theme structures, including custom templates.

The path validation, however, let manipulated inputs through. The pattern involved follows the page-{value}.php format.

Thus, the manipulation allowed escaping the theme's expected folder. The flow would then reach another existing PHP file on the system.

In addition, the fix strengthened exactly this check. According to Patchstack's analysis, the patched version now rigorously confirms whether the resolved path belongs to authorized directories.

Credit for the discovery goes to researcher Robert Ressl, who carried out responsible disclosure with the project.

The two conditions that lead to code execution in WordPress

Full exploitation depends on prerequisites. The first lies in the active theme.

The parent or child theme needs to have a top-level directory starting with page-. The advisory cites examples such as Twenty Twelve, Twenty Fourteen, Neve, Hestia, and Sydney.

The second requirement lies in the server. In addition, there needs to be a local PHP file readable by the web server user and reachable through the flaw.

This distinction matters for inventory purposes. However, relying on the absence of these conditions works poorly as a defense strategy.

PHP enters the chain with register_argc_argv

A specific configuration significantly raises the impact. It concerns the register_argc_argv directive.

When it is enabled, the pearcmd.php file can take part in the chain. In that case, local file inclusion turns into code execution.

However, a technical caveat is worth noting. PEAR appears as a piece of the chain, while the root cause remains in template resolution.

The report points to known at-risk environments. Official PHP configurations in Docker and default cPanel installations with PHP earlier than 8.5 may present the relevant conditions.

WordPress released a fix all the way back to the 4.7 branch

The current series receives 7.1.2. In addition, the project released retroactive fixes for older branches still supported.

Some examples from the list: 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, and 6.5.12. The chain goes all the way to 4.7.37.

Versions 4.6 and earlier were left out. They have already lost security support.

The project's reminder is worth noting. Only the most recent version is considered actively supported.

How to apply the fix now

From the dashboard, the path is short. Go to Dashboard and then Updates, then click Update now.

Before that, make sure you have a recent backup of the database and files. Sites with automatic updates may already have received the patch, but confirm the version manually anyway.

In the terminal, WP-CLI gets it done quickly. Use wp core version to check, wp core check-update to verify, and wp core update to apply it.

Afterward, confirm the version again. In production, keep the procedure controlled, with subsequent validation and testing.

What to review after the patch

Start with the access logs. Look for unusual requests related to page resolution or to PHP files outside the normal flow.

The urgency has a reason. According to Patchstack, probing against sites began just hours after the fix was published.

A single probing attempt, by itself, proves little. However, suspicious signs call for a broader investigation.

In this check, look at modified files, unknown administrative users, altered plugins and themes, scheduled tasks, and processes run by the web server user.

It's also worth reviewing the PHP environment. Check register_argc_argv, the version in use, and unnecessary, accessible local PHP files.

The point agencies and hosting teams need to address

Those who manage many sites have extra work. Review the complete inventory, including old and forgotten installations.

In shared hosting, the check covers every site under administration. After all, the least important site opens the same door as the main one.

Follow our profile on Instagram!