CVE-2026-87902 is the kind of WordPress vulnerability that deserves attention not because every vulnerable installation can immediately be turned into a remote shell, but because several individually ordinary behaviors line up in a dangerous way. A request-controlled page name reaches WordPress’s template resolution logic, URL decoding changes how that value is interpreted, the resulting filename can escape the directory boundary that WordPress expects templates to remain inside, and the PHP runtime may then include a local PHP file chosen by an unauthenticated attacker.
WordPress disclosed the vulnerability on September 22, 2026 and released WordPress 7.1.2 as the primary fixed release. The WordPress security team describes the issue as an unauthenticated path traversal vulnerability in page-template resolution that allows an attacker, under the right conditions, to include a readable local PHP file outside the active theme directories. If additional conditions in both the active theme and server environment are satisfied, that inclusion can be escalated into remote code execution. (WordPress.org)
The official GitHub advisory assigns CVE-2026-87902 a CVSS 4.0 score of 9.2, Critical, with the vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. No authentication or user interaction is required, although the AT:P component is important: successful exploitation depends on prerequisites being present. The issue is associated with CWE-98, Improper Control of Filename for Include/Require Statement in PHP Program. (GitHub)
For defenders, however, CVSS is only part of the story. Patchstack reported that it began seeing probes for the vulnerability at 17:44 UTC on September 22, less than five hours after WordPress 7.1.2 became available. Those requests used traversal patterns corresponding to the newly patched behavior, suggesting that attackers or scanners had rapidly reverse-engineered the public patch. At the time of Patchstack’s report, the observed requests were probes against ordinary WordPress core files rather than confirmed delivery of attacker-controlled PHP payloads, so describing the situation as widespread successful RCE would go beyond the available evidence. What is confirmed is that internet scanning began almost immediately. (Patchstack)
That distinction is important for understanding CVE-2026-87902 correctly.
CVE-2026-87902 at a Glance
| 필드 | 세부 정보 |
|---|---|
| CVE | CVE-2026-87902 |
| 제품 | WordPress Core |
| 취약성 | Path traversal leading to local file inclusion |
| Possible impact | Conditional remote code execution |
| Authentication required | 아니요 |
| User interaction required | 아니요 |
| CVSS v4.0 | 9.2 Critical |
| CWE | CWE-98 |
| Vulnerable range | WordPress 4.7.0 through affected releases up to 7.1.1 |
| Main fixed release | WordPress 7.1.2 |
| Disclosure date | September 22, 2026 |
| Researcher | Robert Ressl |
| Observed internet activity | Active probing reported September 22, 2026 |
WordPress also backported the security fix across older maintained security branches. Fixed releases include 7.0.6, 6.9.9, 6.8.10 and corresponding releases all the way back to WordPress 4.7.37. (GitHub)
What Is CVE-2026-87902?
At its core, CVE-2026-87902 is a failure to enforce a security boundary during WordPress page-template selection.
WordPress themes can provide different PHP files for different pages. A site might have page.php as a generic page template, page-about.php for an About page, or a custom template such as page-templates/full-width.php. WordPress therefore needs logic that takes information about the requested page and turns it into a list of possible template filenames.
That work happens partly inside get_page_template() in wp-includes/template.php.
The relevant logic historically looked roughly like this:
$pagename = get_query_var( 'pagename' );
if ( $pagename ) {
$pagename_decoded = urldecode( $pagename );
if ( $pagename_decoded !== $pagename ) {
$templates[] = "page-{$pagename_decoded}.php";
}
$templates[] = "page-{$pagename}.php";
}The legitimate purpose is easy to understand. WordPress wants to support page names containing encoded or multibyte characters, so it considers both a decoded representation and the original representation when constructing candidate template names. WordPress documentation in the source notes that this decoded form was introduced in WordPress 4.7.0, which also helps explain why the affected version history stretches back to the 4.7 branch. (GitHub)
The security problem appears when the decoded value is not merely an ordinary page slug.
A filename constructed from attacker-influenced input may contain directory components. If those components are able to change how the filesystem resolves the path, the template resolver can cross the boundary separating the active theme from other files accessible to the PHP process.
That transforms what should be a simple question—
Which template inside this theme should render this page?
—into a much more dangerous question:
Which readable PHP file on the server can the application be convinced to include?
That second operation is where CVE-2026-87902 becomes a serious server-side vulnerability.
The Vulnerability Is More Than Simple Directory Traversal
Calling CVE-2026-87902 a “directory traversal vulnerability” is technically useful, but it does not completely describe its security impact.
A traditional path traversal flaw is often discussed in terms of reading files outside an intended directory. An application expects something such as:
/themes/my-theme/templates/examplebut an attacker manipulates path components until the resolved location escapes the intended directory.
With CVE-2026-87902, the destination is important because the affected WordPress code is part of PHP template inclusion. The application is not simply opening a text file and returning its contents to the browser. It is attempting to find and load PHP code as a WordPress template.
This creates a much more powerful primitive.
If an attacker can make WordPress locate a chosen local .php file and PHP proceeds to include that file, then the behavior of the included file becomes part of the attack surface. An otherwise legitimate PHP file somewhere on the server can potentially behave in an unexpected and dangerous way when invoked through this path.
The official WordPress advisory therefore describes the initial capability as inclusion of a chosen readable local PHP file and separately states that it can lead to RCE when the required theme and server conditions are present. (GitHub)
This is the correct way to frame CVE-2026-87902:
Path traversal → local PHP file inclusion → environment-dependent RCE.
Treating all three stages as identical obscures how the vulnerability actually works.
왜 get_page_template() Became the Critical Attack Surface
WordPress’s template hierarchy is one of the platform’s oldest and most important architectural features. When WordPress renders content, it builds an ordered list of files that could represent the requested object.
For a page, WordPress describes a hierarchy similar to:
custom page template
page-{page-name}.php
page-{page-id}.php
page.phpThe page name therefore legitimately participates in filename generation.
That normally looks harmless. A page with the slug:
aboutcan result in WordPress considering:
page-about.phpbefore falling back to page.php.
The problem is that file path construction becomes security-sensitive as soon as an externally influenced string can contain path separators or traversal components. The final security decision can no longer be based solely on the assumption that the string represents a page slug.
There is also an encoding issue. Web applications routinely decode URLs at different layers: the web server may perform processing, the framework may parse the query string, and application code may explicitly call decoding functions again. A string that looks relatively harmless at one stage may have a different filesystem meaning after another decoding step.
CVE-2026-87902 exploited precisely this kind of trust-boundary problem. Patchstack’s technical analysis highlights the interaction between the pagename value, explicit urldecode() behavior and candidate template construction. (Patchstack)
The security lesson extends well beyond WordPress: validation must be performed on the value that will actually reach the filesystem, not merely on an earlier encoded representation.
Why a Theme Directory Matters
One of the more unusual aspects of CVE-2026-87902 is that an affected WordPress version alone does not guarantee the full exploit path.
According to the official advisory, one prerequisite is that the active parent or child theme contains a top-level directory whose name begins with page-, such as:
page-templates/The advisory specifically identifies legacy Twenty Twelve and Twenty Fourteen themes and names several third-party themes, including Neve, Hestia and Sydney, as examples containing relevant layouts. (GitHub)
This requirement emerges from the way WordPress constructs a filename beginning with page-.
Imagine a candidate path conceptually beginning as:
page-templates/...그리고 page- prefix that WordPress intentionally adds can line up with a real theme directory called page-templates. Once the path enters that directory, traversal sequences can potentially navigate back outward.
That is why this is not simply a case where any arbitrary pagename gives an attacker unrestricted filesystem access. The filesystem layout supplied by the active theme participates in the vulnerability.
For defenders, that gives us an important distinction:
A server can be running a vulnerable WordPress core version while lacking one of the conditions needed for the published RCE chain.
That does not make staying unpatched a reasonable strategy. It simply means exposure assessment should distinguish between vulnerable software and immediately exploitable deployment conditions.
LFI Does Not Automatically Mean RCE
Another source of confusion around CVE-2026-87902 is the phrase “LFI to RCE.”
Local File Inclusion and Remote Code Execution are related here, but they are not equivalent.
The first major security boundary crossed by CVE-2026-87902 is the ability to cause WordPress to include a readable .php file that lives outside the theme directories. If the only PHP files available through that primitive perform harmless operations, successful inclusion does not automatically give the attacker a shell.
To turn inclusion into arbitrary code execution, the attacker needs a suitable local PHP file or another behavior that can be abused as an execution gadget.
The WordPress advisory specifically discusses the well-known pearcmd.php PEAR technique as one possible transition. It notes that this route can be relevant when PHP’s register_argc_argv setting is enabled. According to the advisory, the official PHP Docker image is affected by this environmental condition, while default cPanel configurations can also be relevant when using PHP versions before PHP 8.5. (GitHub)
The practical chain can therefore be represented as:
Unauthenticated HTTP request
↓
Attacker-controlled page name
↓
Template filename construction
↓
Path normalization / traversal weakness
↓
Escape from theme directory
↓
Include readable local PHP file
↓
Useful PHP execution gadget exists?
↓
Required PHP configuration enabled?
↓
Remote code executionThe two questions near the bottom matter.
A website should therefore not be described as confirmed RCE-exploitable simply because it runs WordPress 7.1.1. Conversely, defenders should not dismiss the vulnerability because exploitation has prerequisites. Internet-facing WordPress installations frequently run in heterogeneous hosting environments with legacy PHP settings, shared hosting control panels, old themes and years of accumulated files. Conditions that look narrow in isolation can become common at ecosystem scale.
Why the CVSS Score Is 9.2 Despite the Preconditions
The official CVSS vector for CVE-2026-87902 is:
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NSeveral components explain the Critical rating.
AV:N means the vulnerable interface is reachable over the network. PR:N means an attacker does not require a WordPress account. UI:N means exploitation does not depend on convincing an administrator or another user to click something.
The interesting component is AT:P, which reflects attack requirements or prerequisites. In other words, the scoring acknowledges that the environment has to satisfy additional conditions.
But once those conditions exist, compromise can potentially affect confidentiality, integrity and availability at a high level. A successful PHP code execution chain runs inside the context of the vulnerable web application and can therefore become a complete server-side compromise rather than a narrow information-disclosure issue. (GitHub)
This is a good example of why reading only the numeric CVSS score is insufficient. CVE-2026-87902 is both 중요 그리고 conditional. Those descriptions do not contradict each other.
Affected WordPress Versions
The vulnerability reaches unusually far back into WordPress history because the relevant decoded template-name behavior dates to the WordPress 4.7 generation.
The official advisory lists the following affected and corrected branches. (GitHub)
| Vulnerable branch | Fixed version |
|---|---|
| 7.1.0 – 7.1.1 | 7.1.2 |
| 7.0.0 – 7.0.5 | 7.0.6 |
| 6.9.0 – 6.9.8 | 6.9.9 |
| 6.8.0 – 6.8.9 | 6.8.10 |
| 6.7.0 – 6.7.8 | 6.7.9 |
| 6.6.0 – 6.6.8 | 6.6.9 |
| 6.5.0 – 6.5.11 | 6.5.12 |
| 6.4.0 – 6.4.11 | 6.4.12 |
| 6.3.0 – 6.3.11 | 6.3.12 |
| 6.2.0 – 6.2.12 | 6.2.13 |
| 6.1.0 – 6.1.13 | 6.1.14 |
| 6.0.0 – 6.0.15 | 6.0.16 |
| 5.9.0 – 5.9.17 | 5.9.18 |
| 5.8.0 – 5.8.16 | 5.8.17 |
| 5.7.0 – 5.7.18 | 5.7.19 |
| 5.6.0 – 5.6.20 | 5.6.21 |
| 5.5.0 – 5.5.21 | 5.5.22 |
| 5.4.0 – 5.4.22 | 5.4.23 |
| 5.3.0 – 5.3.24 | 5.3.25 |
| 5.2.0 – 5.2.27 | 5.2.28 |
| 5.1.0 – 5.1.25 | 5.1.26 |
| 5.0.0 – 5.0.28 | 5.0.29 |
| 4.9.0 – 4.9.32 | 4.9.33 |
| 4.8.0 – 4.8.31 | 4.8.32 |
| 4.7.0 – 4.7.36 | 4.7.37 |
WordPress emphasizes that only the newest version is actively supported in the normal sense, even though critical security fixes are sometimes backported as a courtesy to older branches. For organizations maintaining old WordPress deployments, the backports provide an immediate emergency patching path, but they should not be interpreted as evidence that indefinitely remaining on WordPress 4.x or 5.x is equivalent to running the current branch. (WordPress.org)
How WordPress Fixed CVE-2026-87902
The interesting part of the CVE-2026-87902 patch is not simply that WordPress blocked one known malicious input pattern.
Patchstack’s analysis notes that the fix adds stronger traversal detection and also introduces broader protection around template resolution so that resolved files must remain within approved theme locations. (Patchstack)
Conceptually, the stronger approach looks like this:
$normalized = wp_normalize_path( $path );
if ( path_contains_traversal( $normalized ) ) {
$real_path = realpath( $path );
// Reject paths that resolve outside approved
// stylesheet/template/theme-compat directories.
}This is a substantially stronger security model than simply looking for one encoding of ../.
There are several ways to represent a traversal path:
../
%2e%2e/
%252e%252e/
mixed encoded separators
multiple decoding layers
normalization edge casesAttempting to blacklist every textual representation is fragile because the representation can change as the request passes through a reverse proxy, web server, PHP runtime and application layer.
Canonical path enforcement asks a better question:
Where does this file actually resolve?
If a template is supposed to come from the active theme, WordPress can resolve the final filesystem path and verify that the file remains underneath an explicitly trusted theme directory.
That converts the security property from input filtering into boundary enforcement.
For filesystem-sensitive code, the latter is normally much harder to bypass.
Attackers Started Looking for CVE-2026-87902 Within Hours
One of the most important facts surrounding CVE-2026-87902 has little to do with PHP itself.
It is the timeline.
WordPress released version 7.1.2 on September 22, 2026. Patchstack later reported detecting the first probing traffic at 17:44 UTC that same day—less than five hours after the patch was published. (Patchstack)
According to Patchstack, the observed requests contained encoding patterns associated with the vulnerability and attempted to include ordinary WordPress files such as:
wp-links-opml.php
wp-includes/functions.php
wp-cron.phpThese were not, by themselves, useful RCE payloads. Patchstack explicitly described what it observed as probes rather than payload delivery. (Patchstack)
This matters because vulnerability reporting often collapses several states into one sentence:
PoC available
Scanning detected
Exploitation attempted
Successful exploitation
RCE achieved
Post-exploitation observedThose are six different things.
For CVE-2026-87902, as of the public reporting examined for this article, defenders have solid evidence that automated internet probing began extremely quickly. That is enough to justify emergency patching. It is not the same as evidence that thousands of servers had already been successfully compromised through the full RCE chain.
Accuracy matters particularly during the first hours of a high-profile CVE, when scanner traffic, security research, threat intelligence and actual malicious exploitation can look superficially similar in HTTP logs.
Patch Diffing Has Collapsed the Defender’s Grace Period
The speed of the CVE-2026-87902 scanning also illustrates a broader change in vulnerability response.
Security patches themselves are intelligence.
When an open-source project publishes a security release, an attacker can compare the old and new code:
old release
↓
git diff
↓
security-relevant change identified
↓
input and sink reconstructed
↓
candidate exploit generated
↓
internet-wide scanningThe attacker does not necessarily need the original researcher’s report.
For a widely deployed open-source application such as WordPress, the vulnerable source and corrected source are both available. Modern automation makes the difference easier to inspect, and the time between disclosure and operational scanning can therefore be measured in hours rather than days.
CVE-2026-87902 appears to be a textbook example. Patchstack said the payload encoding seen in the early probes matched the behavior addressed by the patch, leading its researchers to conclude that the scanner operators were likely working backward from the code change. (Patchstack)
For defenders, “we will patch it this weekend” is becoming a much less comfortable policy for internet-facing critical software.
How to Check Whether a WordPress Site Is Exposed
The first check is simply the WordPress version.
Administrators can verify it through the WordPress dashboard or through WP-CLI:
wp core versionA vulnerable core release should be updated regardless of whether the rest of the environmental prerequisites appear to exist.
The second check is the active theme structure. Administrators should examine the active parent and child themes for top-level directories beginning with page-, particularly directories such as:
page-templates/This does not prove exploitation. It establishes that one of the prerequisites described by the WordPress security advisory exists.
The third check is the PHP environment.
The advisory specifically identifies register_argc_argv as relevant to a known LFI-to-RCE transition involving PEAR. Administrators can inspect the setting without modifying anything:
php -i | grep register_argc_argvor:
php -r 'echo ini_get("register_argc_argv") . PHP_EOL;'Again, the correct interpretation is not:
register_argc_argv = Off
therefore CVE-2026-87902 does not matterIt is:
register_argc_argv = On
one documented RCE prerequisite deserves immediate attentionThere may be other useful local PHP targets in complex hosting environments, which is another reason patching the actual WordPress defect is preferable to trying to prove that no exploitable chain exists.
Detecting CVE-2026-87902 Probing in Web Logs
Patchstack published several useful indicators for identifying early CVE-2026-87902 probing.
One of the highest-signal indicators is a pagename parameter containing double-encoded traversal components such as:
%252e%252eDefenders should also investigate suspicious requests containing combinations of pagename 그리고 page_id, especially when sent to the site root or index.php. Patchstack additionally recommends looking for unexpected output from ordinary core PHP files in responses where a normal WordPress page should have been rendered. (Patchstack)
For Nginx logs, a starting point might be:
grep -Ei 'pagename=.*%25(2e|2f)' access.logFor Apache:
grep -Ei 'pagename=.*%25(2e|2f)' /var/log/apache2/access.logThese should be treated as hunting queries, not perfect CVE signatures. URL logging behavior varies between proxies and web servers, and security appliances may decode request parameters before storing them.
A stronger investigation correlates:
request URI
source IP
timestamp
HTTP status
response size
user agent
WAF decision
upstream PHP logs
filesystem changesAn attempted traversal request returning an error tells a very different story from an unusual request returning HTTP 200 with output associated with the targeted PHP file.
Patchstack specifically notes that unexpected OPML output from a normal page URL can indicate that an inclusion probe actually succeeded. (Patchstack)
What to Do If You Find Suspicious Requests
Finding CVE-2026-87902 scanning in access logs does not automatically mean the WordPress installation was compromised. Public vulnerability scanners often touch huge numbers of servers, including servers that are already patched or not exploitable.
The response should instead answer three progressively stronger questions.
First: Was the request received?
Second: Did the vulnerable template resolution behavior occur?
Third: Did the attacker successfully transition from inclusion into code execution?
A site that was exposed during the vulnerable window should therefore be investigated beyond simple HTTP access logs.
Review recently modified PHP files:
find /var/www -type f -name "*.php" -mtime -7 -printIf WordPress core integrity can be checked through WP-CLI:
wp core verify-checksumsInstalled plugins should also be inventoried:
wp plugin listand administrators should inspect unexpected user accounts:
wp user listFile integrity tools, EDR telemetry and hosting-provider audit logs are substantially more useful than trying to infer compromise from one HTTP request.
A successful RCE event can leave evidence outside the WordPress directory entirely, including processes, scheduled tasks, SSH keys, temporary files and outbound connections. On a confirmed compromise, incident response should therefore treat the host as a system-level investigation rather than merely reinstalling one WordPress PHP file.
Temporary Mitigation Is Not a Substitute for WordPress 7.1.2
For organizations that cannot immediately patch, filtering obviously malicious traversal patterns can reduce short-term exposure.
Patchstack specifically notes that traversal sequences inside pagename should never be required for a legitimate page slug, making them reasonable candidates for blocking at the WAF or reverse proxy layer. (Patchstack)
But WAF mitigation has an unavoidable weakness: the vulnerability itself involves URL encoding and normalization.
Blocking:
../does not necessarily mean you have blocked every representation that later decodes into:
../Security filters may see a different representation than WordPress eventually processes.
A proper patch fixes the trust boundary inside the application. An external filter attempts to guess which inputs might cross that boundary.
For CVE-2026-87902, administrators should therefore update to WordPress 7.1.2 or the corresponding patched release for their branch rather than treating WAF signatures as the final remediation.
WordPress itself recommends immediate updating. (WordPress.org)
Why CVE-2026-87902 Matters Even for Sites That Do Not Meet the Known RCE Conditions
It would be tempting to look at the prerequisites and conclude that the vulnerability is less urgent on a site using a different theme or PHP configuration.
That reasoning misses an important distinction between an exploit chain and a security primitive.
The underlying primitive is the ability to make template resolution include PHP files outside the intended theme directories.
The publicly documented RCE route is one way of turning that primitive into code execution. It should not automatically be treated as the only possible way.
Real WordPress hosting environments are messy. They can contain control-panel packages, Composer dependencies, backup utilities, diagnostic tools, abandoned plugins, temporary files and application-specific PHP scripts. A local file that appears irrelevant to one installation may become a useful execution gadget on another.
This is why the architectural fix matters more than the known proof-of-concept path.
Prevent the path traversal and the attacker loses the primitive.
Try to eliminate only one known PHP gadget and the underlying vulnerability remains.
CVE-2026-87902 Is a WordPress Core Vulnerability, Not a Plugin Bug
Another point worth emphasizing is that CVE-2026-87902 exists in WordPress Core.
The WordPress ecosystem receives a constant stream of plugin and theme vulnerabilities because thousands of independent developers publish extensions. Administrators sometimes respond to WordPress CVE headlines by asking whether they have installed the affected plugin.
That is not the right question here.
The vulnerable page-template resolution behavior lives in WordPress itself. Themes participate in determining whether the known exploit preconditions are present, but installing no vulnerable third-party plugin does not remove the affected core code.
The correct inventory question is therefore:
Which WordPress core version is this server running?followed by:
Which active theme and PHP environment does this installation use?Why the Vulnerability Stayed Hidden for So Long
The behavior connected to CVE-2026-87902 reaches back to WordPress 4.7, released roughly a decade before the 2026 disclosure.
That does not necessarily mean one obvious ../ bug sat untouched in plain sight for ten years.
Mature software often develops vulnerabilities at the intersection of multiple legitimate behaviors. URL decoding is legitimate. Template hierarchy resolution is legitimate. Theme subdirectories are legitimate. Including PHP templates is fundamental to classic WordPress rendering. PHP’s runtime configuration exists for legitimate reasons.
Security failures emerge when assumptions made by those components do not line up.
The template code assumes it is dealing with a page identity.
The filesystem interprets the result as a path.
PHP interprets the selected result as executable source.
The theme provides directory names that influence path structure.
Only when those behaviors are considered together does the complete vulnerability emerge.
This is one reason mature open-source software can continue to produce serious vulnerabilities even after decades of auditing: the number of meaningful states is much larger than the number of individual functions.
The Broader Security Lesson: Validate the Final Resource, Not Just the Input
CVE-2026-87902 is a useful case study for developers building any application that resolves user-influenced filenames.
Consider two models.
The first is input-oriented:
Does this string contain "../"?
Does it contain "%2e"?
Does it look suspicious?The second is resource-oriented:
Normalize the candidate.
Resolve its canonical filesystem path.
Determine the allowed root.
Verify the resolved file remains underneath that root.
Only then load it.The second model expresses the real security requirement.
If templates must live within:
/var/www/example/wp-content/themes/mytheme/then the central question should be whether the canonical resolved target remains beneath that directory.
An attacker can invent many strings.
There is only one filesystem location those strings ultimately resolve to.
The CVE-2026-87902 patch is important because WordPress moved toward enforcing the latter property rather than relying exclusively on assumptions about what a page slug should look like. Patchstack’s review of the fix highlights this broader path-boundary validation. (Patchstack)
WordPress Administrators Should Patch Before Spending Hours Testing Exploitability
There is a common operational mistake following vulnerabilities like CVE-2026-87902: teams spend hours trying to prove whether the exploit works against their specific installation before approving the patch.
For this CVE, that ordering is difficult to justify.
The update is already available.
The vulnerability is in WordPress Core.
No authentication is required.
Affected releases go back to 4.7.
The official severity is Critical.
Public scanning began within hours.
That combination makes patching the first containment action, not the conclusion of the investigation.
Testing still has value after remediation. Teams may need to establish whether they were exposed, whether known prerequisites existed and whether suspicious requests arrived during the vulnerable period. Those questions matter for incident response.
But determining whether an attacker could theoretically achieve RCE should not delay removal of the underlying path traversal primitive.
CVE-2026-87902 FAQ
Is CVE-2026-87902 a WordPress vulnerability?
Yes. CVE-2026-87902 affects WordPress Core’s page-template resolution logic rather than a single third-party plugin. The issue was fixed in WordPress 7.1.2 and backported to older WordPress security branches. (WordPress.org)
Is CVE-2026-87902 remotely exploitable?
The vulnerable functionality is reachable remotely and does not require authentication. The attacker can potentially cause WordPress to include a readable local PHP file outside the expected theme directories. Achieving RCE requires additional environmental prerequisites. (GitHub)
Does CVE-2026-87902 automatically give an attacker RCE?
No. The primary primitive is path traversal leading to local PHP file inclusion. Remote code execution becomes possible when additional conditions are present, including a suitable theme directory structure and a usable local PHP execution target. The official advisory documents one PEAR-related route involving register_argc_argv. (GitHub)
Does CVE-2026-87902 require authentication?
No. The official advisory describes the vulnerability as unauthenticated. Its CVSS vector also contains PR:N, meaning no privileges are required. (GitHub)
What is the CVSS score for CVE-2026-87902?
The WordPress GitHub Security Advisory assigns CVE-2026-87902 a CVSS 4.0 score of 9.2 Critical. (GitHub)
Which WordPress version fixes CVE-2026-87902?
WordPress 7.1.2 fixes the vulnerability on the latest branch. WordPress also released backported security versions for older branches, including 7.0.6, 6.9.9, 6.8.10 and patches down to 4.7.37. (GitHub)
Is CVE-2026-87902 being exploited in the wild?
Patchstack reported active probing beginning on September 22, 2026, less than five hours after the WordPress 7.1.2 patch appeared. The requests it described were primarily vulnerability probes targeting ordinary WordPress files, not evidence that every request achieved RCE. The most precise description based on currently published evidence is therefore active probing observed in the wild. (Patchstack)
How can I detect CVE-2026-87902 attacks?
Administrators should search HTTP logs for suspicious pagename parameters, especially double-encoded traversal sequences such as %252e%252e, and investigate abnormal combinations of pagename 그리고 page_id. Unexpected content returned from ordinary page requests can provide stronger evidence that local file inclusion actually occurred. (Patchstack)
Should I disable register_argc_argv instead of updating WordPress?
No. Disabling unnecessary PHP functionality can reduce exposure to one documented RCE transition, but it does not fix the WordPress path traversal vulnerability. Updating WordPress remains the appropriate remediation.
Final Analysis
CVE-2026-87902 is significant because it crosses one of the most important security boundaries in a PHP application: the boundary between user-influenced routing data and executable filesystem paths.
The vulnerable WordPress code was intended to answer an ordinary presentation-layer question—what PHP template should render this page? Under the wrong conditions, attacker-controlled path information could turn that routine lookup into the inclusion of a local PHP file outside the active theme. Once that primitive exists, the server’s PHP configuration and available local files determine whether the attack ends at LFI or continues into remote code execution.
That nuance should not reduce the urgency of the vulnerability. It should make the response more precise.
WordPress has released 7.1.2 and backported the fix throughout affected security branches. The flaw requires no authentication. The vulnerable behavior existed across releases dating back to the WordPress 4.7 generation. The official severity is 9.2 Critical. Most importantly, defenders did not receive a comfortable grace period: Patchstack reported internet probing less than five hours after the patch became public. (Patchstack)
For WordPress operators, the practical sequence is straightforward: patch first, determine whether the known environmental prerequisites existed, review historical request logs for traversal probes, and investigate the host more deeply if there is evidence that file inclusion succeeded.
For security engineers, CVE-2026-87902 carries a broader lesson. Whenever untrusted data participates in template selection, module loading, file inclusion or filesystem routing, filtering suspicious strings is not enough. The application should resolve the final resource and prove that it remains inside the directory the security model intended.
That is ultimately what CVE-2026-87902 exposed: not simply an unusual URL encoding trick, but a broken filesystem trust boundary inside one of the world’s most widely deployed web application platforms.
Korean 
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Hindi 
Arabic 
Turkish 
Hebrew