New WordPress Pre-Authentication XSS Could Lead to PHP Code Execution, Patch Immediately

WordPress has released emergency security updates to address a high-severity vulnerability that affects virtually every supported installation of the world’s most widely deployed content management system. Tracked as CVE-2026-64638, the flaw exists within WordPress Core and allows an unauthenticated attacker to trigger a reflected cross-site scripting (XSS) condition on the login page. While reflected XSS vulnerabilities are common across web applications, this particular issue attracted immediate attention because researchers at pwn.ai demonstrated that, under the right conditions, it can be chained into PHP code execution on the server.

The distinction between the vulnerability itself and the complete attack chain is important. The underlying XSS requires no authentication and can be triggered by any attacker capable of convincing a victim to visit a specially crafted login URL. The subsequent transition from browser-side JavaScript execution to server-side PHP execution is considerably more complex and depends on additional prerequisites, including an already authenticated WordPress administrator interacting with attacker-controlled content. WordPress has therefore taken a more conservative position regarding exploitability than the researchers, emphasizing that remote code execution is not an inherent property of the XSS itself but rather the result of a multi-stage exploit chain involving social engineering and browser behavior.

Regardless of where one falls in that assessment, the security implications are significant. WordPress powers a substantial portion of the modern web, and even vulnerabilities requiring multiple conditions deserve immediate attention because of the enormous number of exposed installations. A flaw that affects millions of websites simultaneously presents attackers with a vast opportunity, particularly once proof-of-concept techniques become publicly available.

The issue was fixed on August 6, 2026, in WordPress 7.0.3, with security backports extending to all supported release branches down to version 4.7. Installations running versions older than 4.7 remain vulnerable but no longer receive official security updates, leaving administrators responsible for upgrading to a supported release.

At the time of writing, WordPress has not reported evidence of active exploitation in the wild. Nevertheless, security researchers expect scanning activity and exploit development to increase rapidly following public disclosure, making timely patching the most effective mitigation.

Executive Summary

CVE-2026-64638 is fundamentally a reflected cross-site scripting vulnerability affecting the WordPress login interface. Unlike plugin-specific issues that impact only a subset of deployments, this vulnerability resides within WordPress Core itself, meaning it affects default installations without requiring any third-party extensions.

The vulnerability originates from an inconsistency in how different parts of WordPress process user-supplied input. Specifically, data passes through multiple sanitization and HTML parsing routines that do not interpret malformed HTML identically. Under carefully crafted conditions, text that one parser considers harmless survives processing and is later interpreted by another parser as executable HTML. The discrepancy ultimately allows attacker-controlled elements to appear within the Document Object Model (DOM) of the login page.

By itself, this behavior results in reflected XSS. However, the researchers demonstrated that the injected DOM elements can interfere with JavaScript already present on the page, altering how WordPress’s own client-side scripts behave. Through a sequence involving DOM clobbering, JSONP, Same Origin Method Execution (SOME), and the Application Password feature, the browser can be coerced into performing authenticated actions on behalf of an administrator. One demonstrated path ultimately uploads a malicious plugin archive, after which arbitrary PHP code can be executed from the extracted files.

Although the exploit chain is sophisticated, every stage builds upon legitimate WordPress functionality rather than memory corruption or operating system vulnerabilities. This makes the research particularly interesting from a defensive perspective because it demonstrates how individually benign features can interact in unexpected ways to create a much more serious outcome.

Affected Versions

According to WordPress, the vulnerability affects every supported release prior to the publication of the August 2026 security update.

The issue is fixed in:

• WordPress 7.0.3
• Security backports for all supported branches down to 4.7

Versions older than 4.7 remain affected but fall outside WordPress’s supported maintenance window.

Sites configured for automatic background security updates should receive the fix automatically. Administrators who disable automatic updates or maintain custom deployment pipelines should verify that the appropriate security release has been applied manually.

Discovery and Responsible Disclosure

The vulnerability was discovered by researchers at pwn.ai, who named the complete attack chain XSS2Shell. According to the researchers, the work originated from experiments using an autonomous multi-agent workflow designed to reproduce and extend previously published browser exploitation techniques.

Rather than beginning from scratch, the system was provided with Paulos Yibelo’s 2022 research on Same Origin Method Execution (SOME), a browser exploitation technique that enables JavaScript running within one origin to invoke methods inside another same-origin browser window. The researchers report that their autonomous workflow spent nearly four days exploring possible attack paths before independently discovering a chain that transformed a reflected login-page XSS into PHP code execution.

The researchers reproduced the attack on July 26, 2026, and responsibly disclosed the findings to the WordPress security team the following day.

WordPress acknowledged the report, developed patches, coordinated the release across supported branches, and credited the researchers after the public disclosure.

The disclosure process also highlights a healthy disagreement that occasionally appears during coordinated vulnerability handling. While the researchers demonstrated a practical route to PHP execution under controlled conditions, WordPress emphasized that the escalation requires additional attacker-controlled circumstances beyond the initial vulnerability itself. Specifically, an authenticated administrator must already be logged into the affected site and must interact with attacker-controlled content, introducing dependencies that cannot be guaranteed by an attacker in every environment.

This distinction does not diminish the seriousness of the issue but helps administrators understand the practical risk model. The vulnerability should not be viewed as an unauthenticated remote code execution flaw in the traditional sense. Instead, it represents a highly capable reflected XSS that researchers successfully chained into code execution through additional browser-side techniques and legitimate WordPress functionality.

Understanding the Threat Model

One of the reasons this disclosure generated significant discussion within the security community is that it blurs the boundary between client-side and server-side compromise.

When administrators hear the phrase “PHP code execution,” the natural assumption is that a memory corruption vulnerability, insecure file upload, authentication bypass, or deserialization flaw has been discovered. None of those are true in this case.

Instead, every stage of the attack occurs within the browser before eventually influencing server-side behavior.

Initially, the attacker only controls content rendered inside the victim’s browser. The browser then executes JavaScript within WordPress’s origin because the reflected XSS bypasses the intended sanitization logic. From there, the exploit manipulates existing WordPress JavaScript, abuses browser trust relationships, leverages authenticated administrator privileges already present within the browser session, requests an Application Password through legitimate interfaces, authenticates against the REST API, uploads a plugin archive using valid administrative permissions, and finally causes PHP code residing inside that uploaded archive to execute.

At no point does the attacker exploit a memory safety issue within PHP, Apache, Nginx, or WordPress itself. Instead, the browser effectively becomes the vehicle through which authenticated administrative operations are performed.

This distinction is increasingly relevant because modern web applications expose extensive administrative functionality through REST APIs, asynchronous JavaScript, and browser-side components. As these ecosystems become more interconnected, vulnerabilities capable of steering trusted browser behavior often become far more dangerous than their initial classification might suggest.

Why This Vulnerability Matters More Than a Typical Reflected XSS

Reflected cross-site scripting has existed for decades and is often viewed as less severe than stored XSS because the malicious payload is not permanently saved on the server. Instead, the attacker typically needs to convince each victim individually to visit a specially crafted URL or submit malicious input.

In many enterprise environments, reflected XSS primarily enables credential theft, session hijacking, phishing, interface manipulation, or limited browser-side attacks.

CVE-2026-64638 is different because the reflected XSS is only the first stage of a considerably larger exploit chain.

Rather than focusing on stealing administrator cookies or displaying fake login prompts, the researchers investigated whether trusted JavaScript already present within WordPress could be influenced into performing privileged operations automatically. This shift in perspective transforms the vulnerability from a conventional browser issue into an application workflow problem, where legitimate functionality is combined in unintended ways to achieve a far more impactful result.

Equally noteworthy is that the attack does not depend on obscure plugins, custom themes, or unusual hosting configurations. According to the researchers, the demonstrated chain worked against default WordPress installations without requiring non-standard deployment settings. That universality significantly increases the potential impact, even if the later stages still require administrator interaction.

The remainder of the exploit hinges on subtle inconsistencies deep within WordPress’s input handling pipeline. Understanding why the reflected XSS exists requires examining how user-controlled input travels through multiple sanitization routines, each of which interprets malformed HTML differently. Those parser inconsistencies ultimately create the conditions that allow attacker-controlled HTML to survive filtering and become executable within the login page.

Root Cause Analysis: How a Parser Inconsistency Becomes a Reflected XSS

At first glance, the vulnerable code path appears to perform multiple layers of sanitization before any user-controlled data reaches the browser. The username supplied during a failed login attempt passes through functions specifically intended to remove unsafe content, making the presence of an XSS vulnerability seem counterintuitive. The issue is not that WordPress neglected to sanitize the input. Instead, the vulnerability stems from different components interpreting the same malformed HTML differently, creating a parser differential that allows attacker-controlled markup to survive one stage and become active in another.

This class of vulnerability has appeared in several large web applications over the years. It illustrates an important security principle: applying multiple sanitization functions does not automatically improve security if those functions implement different parsing rules. When one parser treats input as harmless text while another later interprets the same bytes as HTML, assumptions made during the first validation stage no longer hold.

In CVE-2026-64638, the discrepancy occurs as the supplied username moves through several WordPress and PHP functions before ultimately being rendered back to the user after an unsuccessful login attempt.

The Failed Login Processing Pipeline

When a user enters incorrect credentials, WordPress redisplays the login form along with an error message indicating that authentication failed. To improve usability, the username entered by the visitor is echoed back into the page so it does not need to be typed again.

Before that value is rendered, it passes through several processing stages intended to remove invalid or potentially dangerous content. According to the technical analysis published by pwn.ai, the relevant path involves:

1. sanitize_user()
2. wp_strip_all_tags()
3. PHP’s native strip_tags()
4. wp_kses_post()

Each function has a legitimate purpose, but they are designed to solve different problems.

sanitize_user() is responsible for normalizing usernames according to WordPress rules. It removes characters that are not considered valid for user identifiers and performs additional cleanup to produce a canonical username format.

The resulting value is then processed by wp_strip_all_tags(), which internally relies on PHP’s strip_tags() function. At this stage, the intention is straightforward: anything that resembles HTML markup should be removed before the username is displayed.

Finally, before the content is inserted into the page, WordPress processes it through wp_kses_post(). This function belongs to the KSES filtering framework, which determines what HTML elements and attributes are permitted within WordPress content. It is commonly used throughout WordPress to allow a restricted subset of HTML while removing dangerous constructs such as event handlers or script tags.

Individually, none of these functions are inherently insecure. The problem is that they do not agree on where HTML begins and ends when confronted with carefully malformed input.

The Parser Differential

The vulnerability relies on an unusual edge case involving malformed HTML containing whitespace immediately after an opening angle bracket.

Instead of supplying ordinary HTML tags such as:

<script>

the attacker crafts input that resembles a tag but is malformed in a way that causes PHP’s strip_tags() parser to classify it differently from the parser later used by wp_kses_post().

According to the researchers, the malformed sequence survives strip_tags() because PHP interprets it as ordinary text rather than an HTML tag. Since the parser does not believe valid markup exists, nothing is removed.

Later, however, wp_kses_post() performs its own independent parsing pass. Unlike strip_tags(), the KSES parser recognizes portions of that same input as legitimate HTML. The content therefore transitions from inert text into active DOM elements during rendering.

This disagreement between two independent parsers is the foundation of the vulnerability.

From the application’s perspective, the username has already been sanitized. From the browser’s perspective, executable HTML has just appeared inside the page.

Neither parser is necessarily “wrong” according to its own implementation. They simply follow different parsing rules, and that inconsistency creates a security boundary failure.

Parser differential vulnerabilities are notoriously difficult to identify because each individual function appears to behave correctly when tested in isolation. Only when multiple parsers process the same data sequentially does the dangerous behavior emerge.

Why Multiple Sanitization Layers Failed

A common misconception in web application security is that applying more filters always produces stronger protection.

In reality, chaining multiple sanitization routines can sometimes reduce security if each routine uses a different grammar.

Imagine two translators reading the same sentence in different languages. The first concludes that a particular word is meaningless and leaves it untouched. The second interprets that same sequence as an instruction rather than ordinary text. Neither translation is inherently incorrect, yet combining them changes the meaning entirely.

Exactly the same principle applies here.

The first parser decides:

“This is not HTML.”

The second parser decides:

“This is valid HTML.”

Because the application trusted the first decision, the second parser ultimately receives content that should never have reached it.

This type of issue is fundamentally different from classic input validation failures. WordPress did attempt to sanitize the username, but later processing invalidated the assumptions established earlier in the pipeline.

How the Browser Ultimately Sees the Input

After processing completes, the username is reflected into the failed-login page.

Browsers do not care how many sanitization functions previously executed on the server. They only interpret the final HTML document delivered over HTTP.

Once KSES has reconstructed HTML elements from attacker-controlled input, the browser parses those elements normally and inserts them into the Document Object Model.

At that moment, the attack transitions from a server-side parsing issue into a client-side DOM manipulation problem.

The injected elements become indistinguishable from legitimate page content.

They participate in DOM queries.

They may possess IDs or names.

They may interfere with existing JavaScript.

They may influence browser behavior in unexpected ways.

This is where the exploit becomes considerably more interesting.

From Reflected XSS to DOM Manipulation

Ordinary reflected XSS usually ends with arbitrary JavaScript execution.

An attacker injects a <script> tag, steals cookies, captures keystrokes, or redirects victims elsewhere.

The researchers behind XSS2Shell pursued a different direction.

Instead of immediately executing custom JavaScript to steal data, they examined whether existing JavaScript already shipped with WordPress could be manipulated into performing privileged operations.

Modern web applications include thousands of lines of client-side JavaScript responsible for user interfaces, asynchronous requests, REST interactions, profile management, media uploads, and administrative workflows.

If attacker-controlled DOM elements can subtly alter how those scripts operate, the application’s own code effectively becomes part of the exploit.

That is precisely what occurs in this attack chain.

Why user-profile.js Matters

One of the more surprising aspects of the disclosure is that the critical JavaScript file involved is not primarily associated with the login page.

WordPress includes a script named user-profile.js, which is responsible for handling various profile-related functionality, including password management.

Although administrators typically associate this script with user profile pages inside the dashboard, portions of its functionality are also loaded on the login interface because the login page supports password reset and account recovery operations.

This seemingly harmless implementation detail significantly expands the attack surface.

Once reflected XSS enables attacker-controlled DOM elements to appear on the login page, they coexist alongside JavaScript that was originally written with assumptions about the structure of the DOM.

Those assumptions become exploitable.

The Missing Elements Problem

According to pwn.ai’s analysis, user-profile.js expects certain form fields to exist.

On the actual profile page, those elements are present.

On the login page, they are not.

Instead of throwing fatal errors, JavaScript resolves those missing references as undefined.

Under specific conditions, equality comparisons involving those undefined values unexpectedly succeed, allowing portions of the script to continue executing despite required elements being absent.

While this behavior alone does not produce code execution, it allows the exploit to advance deeper into logic that developers never intended to run from the login page.

This illustrates another recurring security lesson.

Modern JavaScript frequently assumes that the surrounding HTML matches the page on which it was originally designed to execute.

When attacker-controlled HTML modifies that environment, previously unreachable execution paths may suddenly become available.

Introducing DOM Clobbering

The next stage of the exploit relies on a browser technique known as DOM clobbering.

DOM clobbering exploits the fact that browsers historically expose certain HTML elements as global JavaScript variables.

If a page contains an element whose identifier matches the name of a global variable expected by application code, the injected element can replace or interfere with that variable.

Although modern browsers have reduced many historical DOM clobbering behaviors, compatibility requirements mean several mechanisms still exist today.

According to the researchers, WordPress’s JavaScript references a global variable named ajaxurl.

Normally this variable identifies the endpoint used for asynchronous requests.

On the login page, however, ajaxurl is undefined.

That absence becomes exploitable because the attacker’s injected HTML can introduce a DOM element whose identifier collides with the expected variable name.

Instead of remaining undefined, JavaScript now resolves ajaxurl to the attacker-controlled DOM element.

The script proceeds as though a legitimate endpoint has been configured, but the underlying value has effectively been substituted through browser behavior rather than direct JavaScript modification.

This is one of the most elegant stages of the attack because no traditional script injection is required to alter application logic.

The browser’s own name resolution rules perform the substitution automatically.

Once the attacker gains influence over ajaxurl, WordPress’s own JavaScript begins directing requests toward attacker-selected same-origin endpoints, laying the groundwork for the next stage of the chain involving the REST API, JSONP, Same Origin Method Execution (SOME), Application Password abuse, authenticated REST access, malicious plugin upload, and ultimately PHP code execution.

Exploiting WordPress’s REST API Through JSONP

After manipulating user-profile.js into issuing attacker-influenced requests, the next objective is to transform those requests into executable JavaScript within the trusted WordPress origin. The researchers achieved this by leveraging WordPress’s support for JSONP (JSON with Padding), a legacy technique originally introduced to bypass the browser’s same-origin policy before Cross-Origin Resource Sharing (CORS) became widely adopted.

Unlike ordinary JSON responses, JSONP wraps data inside a JavaScript callback function. Rather than returning a document such as:

{
  "status": "ok"
}

a JSONP endpoint returns something similar to:

callback({
    "status": "ok"
});

Because the browser interprets the response as JavaScript instead of data, the returned payload executes immediately when loaded through a <script> element. Historically, this provided developers with a convenient method of retrieving cross-domain data, but it also created opportunities for abuse whenever an application unintentionally allowed attacker-controlled callback behavior.

The XSS2Shell chain takes advantage of this characteristic. Once the attacker can influence where WordPress’s own JavaScript sends requests, JSONP becomes a mechanism for executing code under the site’s trusted origin rather than simply retrieving structured data.

An additional obstacle arises when anonymous REST requests receive an HTTP 401 Unauthorized response. Under normal circumstances, browsers and libraries would treat such responses as failures, preventing subsequent script execution. According to the researchers, the exploit circumvents this behavior using the REST API’s _envelope=1 parameter. Instead of returning a bare 401 response, WordPress wraps the error inside an HTTP 200 response while preserving the underlying status information within the JSON body. Since jQuery evaluates the successful HTTP response rather than rejecting it outright, the payload continues through the intended execution path. This subtle implementation detail ensures that the attack chain remains functional even when unauthenticated REST requests are denied.

Revisiting Same Origin Method Execution (SOME)

The browser-side execution obtained through JSONP is not yet sufficient to compromise the server. The researchers therefore build upon Paulos Yibelo’s Same Origin Method Execution (SOME) technique, originally presented in 2022.

SOME differs from traditional cross-site scripting. Rather than injecting arbitrary JavaScript directly into a privileged page, it abuses existing browser relationships between windows that share the same origin. If one window already possesses elevated privileges because an administrator is logged in, another same-origin context may be able to invoke methods exposed by that privileged window without directly stealing cookies or credentials.

The exploit demonstrated by pwn.ai adapts this concept to modern WordPress. Instead of attempting to hijack the administrator’s authenticated session outright, it persuades the browser to perform legitimate actions already available to that session. From the server’s perspective, every request appears to originate from a valid administrator operating through an authenticated browser. No authentication bypass occurs because the administrator’s session is already trusted.

This distinction is significant because many defensive controls focus on protecting authentication tokens. Here, the attacker does not need to extract or replay those tokens. The browser simply performs the privileged operations on the attacker’s behalf.

Abusing Application Passwords Instead of Stealing Credentials

One of the more innovative aspects of the published exploit is its use of Application Passwords, a feature introduced to allow external applications to authenticate against the WordPress REST API without exposing an administrator’s primary password.

Application Passwords are long-lived credentials that can be generated by authenticated users, revoked individually, and restricted to API access. They are intended to improve security by avoiding the reuse of account passwords across third-party tools.

Rather than viewing this feature as a target, the researchers treated it as an opportunity.

Through the browser-side execution already established, the exploit triggers WordPress’s native Application Password approval workflow from within the administrator’s authenticated session. Once the approval process completes, WordPress creates a new API credential and redirects it to an attacker-controlled success_url over HTTPS.

At no point does the exploit recover the administrator’s actual password. The browser willingly generates a separate credential designed for API access and delivers it through a workflow that WordPress itself considers legitimate.

This approach reduces the attack’s dependence on credential theft while simultaneously providing authenticated REST access capable of performing administrative operations.

From REST Access to Plugin Upload

Possessing a valid Application Password fundamentally changes the attacker’s capabilities.

The credential grants authenticated access to WordPress’s REST API under the administrator’s privileges, allowing the attacker to interact with endpoints that would otherwise require full administrative authentication.

The researchers demonstrated one path in which the newly acquired credential publishes a WordPress page containing additional same-origin JavaScript. When the administrator later accesses that page while still logged in, the embedded script requests the nonce required for plugin uploads.

WordPress protects many sensitive operations using nonces, which function as cryptographically generated tokens intended to prevent cross-site request forgery. Because the administrator is already authenticated, the browser can legitimately obtain a valid upload nonce through normal application behavior.

Once the nonce becomes available, the exploit uploads an attacker-supplied ZIP archive containing a malicious plugin.

Importantly, the plugin does not need to be activated.

The uploaded archive is extracted onto the server as part of WordPress’s standard installation process. If the archive contains a PHP file accessible through the web server, the attacker can request that file directly, causing PHP to execute it with the privileges assigned to the web application.

This final step transforms what began as reflected cross-site scripting into arbitrary server-side PHP execution.

Why Plugin Activation Is Unnecessary

Many administrators associate plugin-based attacks with the requirement that a plugin be installed and explicitly activated before any code executes.

The demonstrated chain challenges that assumption.

Plugin installation extracts the archive into WordPress’s plugin directory regardless of whether activation occurs. PHP files residing inside that directory remain accessible unless additional web server restrictions have been configured.

Consequently, requesting the uploaded PHP file directly through the browser causes the server to execute it even though WordPress never activates the plugin through its administrative interface.

The result is arbitrary PHP execution running with the permissions of the web server process.

Although those permissions are generally lower than root privileges, they remain sufficient to compromise the application completely.

Potential Impact

The consequences of successful PHP execution extend well beyond website defacement.

A compromised WordPress installation may expose database credentials stored within wp-config.php, allowing attackers to access or modify all application data. Additional administrator accounts can be created to establish long-term persistence, while existing content may be altered to distribute malware, phishing pages, or search-engine spam.

Depending on server configuration, attackers may also read files accessible to the PHP process, recover API keys, cloud credentials, SMTP passwords, OAuth secrets, or other sensitive configuration data inadvertently stored on disk.

Where hosting environments reuse the same PHP worker across multiple applications or maintain weak filesystem isolation, the compromise could extend beyond the original WordPress installation.

The exact impact depends on the hosting architecture and operating system permissions, but the vulnerability should be treated as a complete compromise of the affected WordPress instance if the full exploit chain succeeds.

WordPress’s Assessment

Although pwn.ai demonstrated a practical route from reflected XSS to PHP execution, WordPress deliberately distinguishes between the underlying vulnerability and the complete exploitation chain.

The official advisory notes that server-side code execution depends upon conditions outside an attacker’s direct control, including successful social engineering, an already authenticated administrator, and explicit interaction with attacker-controlled content. These additional prerequisites reduce the likelihood of opportunistic exploitation compared with vulnerabilities that permit unauthenticated remote code execution directly against the server.

This distinction is important when assessing operational risk. CVE-2026-64638 should not be viewed as a conventional pre-authentication RCE in which a single malicious HTTP request compromises the server. Instead, it is a high-severity reflected XSS that researchers have shown can be escalated through a carefully constructed sequence of browser interactions and legitimate WordPress functionality.

Nonetheless, organizations should not underestimate the threat. History has repeatedly demonstrated that sophisticated multi-stage attacks often become easier to reproduce once proof-of-concept techniques enter the public domain. Administrative users remain attractive targets for phishing and social engineering, and the ubiquity of WordPress significantly increases the potential value of any broadly applicable exploitation technique.

Detection and Defensive Guidance

At the time of disclosure, neither WordPress nor the researchers reported evidence of active exploitation in the wild. Even so, defenders should assume that public technical details will encourage rapid experimentation.

Administrators should prioritize upgrading to WordPress 7.0.3 or the corresponding security backport for their supported release branch. Sites that rely on automatic background updates should verify that the update completed successfully, while organizations using staged deployment pipelines should ensure every production instance has received the patched version.

Security teams should also review authentication logs for unusual failed login requests containing malformed usernames, inspect web server access logs for unexpected requests to plugin directories, and monitor administrative actions involving Application Password creation, plugin uploads, or newly created administrator accounts. Although none of these events independently confirms exploitation, unusual combinations occurring within a short timeframe warrant immediate investigation.

Organizations operating Web Application Firewalls may consider deploying temporary detection rules for suspicious login requests while patches are rolled out. However, filtering malformed usernames alone should not be considered a substitute for upgrading because the vulnerability ultimately stems from inconsistent parsing behavior within WordPress Core.

Conclusion

CVE-2026-64638 demonstrates how seemingly minor inconsistencies between independent parsing components can evolve into far more serious security issues when combined with modern browser behavior and complex application workflows. The reflected XSS itself originates from a parser differential between PHP’s strip_tags() implementation and WordPress’s KSES filtering logic, but the broader XSS2Shell chain illustrates how client-side trust assumptions, DOM clobbering, JSONP, SAME, Application Passwords, and authenticated REST functionality can be composed into a practical route toward server-side PHP execution.

While WordPress correctly notes that this escalation requires administrator interaction and additional environmental conditions, the research serves as a reminder that the security of large web applications increasingly depends not only on individual features, but also on the often unexpected ways those features interact. For administrators, the recommended course of action is straightforward: apply the August 2026 security updates immediately, verify that all supported installations have been upgraded, and treat any unexplained administrative activity occurring before patching as a potential indicator of compromise.