XSS Vulnerability on WordPress that can climb to PHP and the urgency to patch now

WordPress published on August 6 a patch that fixes a vulnerability of crosss-site scripting (XSS) reflected on the access screen which, according to public discovery, can be chained to PHP code execution under certain conditions. The failure was reported by the company pwn.ai and registered as CVE-2026-64638 (CVSS score 8.9). WordPress included the correction in version 7.0.3 and applied it retroactively to branch 4.7; facilities with enabled automatic updates should receive the patch without intervention from the administrator. The CVE reference is available in the NVD database: https: / / nvd.nist.gov / vuln / detail / CVE-2026-64638, and the official WordPress security ad in your news category: https: / / wordpress.org / news / category / security /.

What is confirmed by pwn.ai is that the XSS is of a reflected type and accessible from the login page without authentication: a specially formed user name sent in a failed access attempt can reach the end user within the error page and run JavaScript in the browser. That JavaScript, according to the company, can be chained with other WordPress behaviors to cause same-origin requests that allow additional control within the site session. WordPress, in its public advice, describes a more cautious assessment: climbing from that XSS to running code on the server (CERs) requires conditions outside the attacker's control - in particular, the interaction and explicit approval of an administrator - and therefore requires success in social engineering in addition to initial vulnerability.

Technically, the failure arises from a conflict between different filters that WordPress applies to the user name value after a failed access attempt. In a simplified and verified way by researchers, the data goes through sanitize _ user () and wp _ strip _ all _ tags () (using the PHP strip _ tags () function). Chains that look like HTML tags but contain spaces immediately after the sign "<" can survive that first processed as text. Below, WordPress applies wp _ kses _ post (), whose parser interprets that same entry as HTML allowed, resulting in the insertion of DOM elements controlled by the attacker into the login error page. These elements end up interacting with user-profile.js, a profile management script that is loaded on the login page by the handling of password restoration; the absence of certain fields expected in that context leaves variables in undefined state and allows an injected overwrite element, for example, ajaxurl, redirecting the JavaScript logic to a request selected by the attacker. pwn.ai also showed how to take advantage of JSONP compatibility in the WordPress REST API to convert the response to JavaScript code executed with the site origin. In environments where the API responds 401 for anonymous requests, the _ envelope = 1 parameter can wrap that denial with an external 200 and make jQuery process the response as script.

The researchers called their XSS2Shell chain and describe multiple routes to PHP execution. One of the demonstrations played by pwn.ai uses the XSS to invoke the native application passwords approval interface within a session already authenticated with the role of Administrator. That interface creates an API credential and redirects to a successful URL controlled by the attacker; with the created credential, the attacker can publish a page containing JavaScript same-origin and, when an authenticated administrator opens it, that script gets the nonce to upload plugins and makes the upload of a ZIP file containing PHP code. In the pwn.ai concept test the PHP code could be requested directly from the extracted plugin without the need to activate the plugin. Important: pwn.ai separated the steps into different tests: the XSS reproduction on remote servers was performed in WordPress facilities 7.0.2 without session cookies, while the complete demonstration that comes to PHP execution was done in a clean local environment.

What is confirmed: There is an XSS reflected on the login page without authentication and WordPress published a patch on August 6. pwn.ai locally reproduced the complete chain until PHP execution and demonstrated the exploitation of the Application Passwords path in laboratory. WordPress recognized the finding, accredited the team and issued the security update; at the close of the public evidence (August 7) there were no verified reports of exploitation in nature.

What is estimate or still uncertain: the extent to which this chain is being actively exploited against production sites is not confirmed; the escalation to CERs requires the interaction of an authenticated administrator and, according to WordPress, social engineering elements that are outside the technical control of the attacker. The effectiveness of partial mitigation (e.g. complex CSP policies or certain hardenings) was tested by researchers in some scenarios and found that a Nonce-based CSP policy with strict-dynamic did not prevent demonstration, but behavior may vary according to plugins, settings and server versions.

Who's it to? Virtually any WordPress installation that has not applied the update: researchers ensure that the chain works against default facilities and does not require unusual hosting configurations. The facilities prior to branch 4.7 are outside the backport support and therefore remain exposed if they are not updated or parked manually.

Consequences of a complete operation would be serious: obtaining credentials stored in wp-config.php, persistent creation of administrative accounts, uploading and execution of PHP code, modification or deletion of content and exposure of files or secrets accessible by the PHP process. The actual extent of damage depends on the server context (PHP worker privileges, filesystem measurements, backups availability and integrity controls).

Practical and specific measures to be implemented by managers today: update to WordPress 7.0.3 or other version that includes the correction; if the update is not possible immediately, minimize access file exposure: protect wp-login.php with additional HTTP authentication or restrict your IP access, activate a WAF with rules that block injections in login parameters, disable plugin / theme editing from the dashboard, revoke recently created Application Passwords and audit the list of credentials. After the update, review the site looking for new administrative accounts or plugin / themes modifications and check file integrity and presence of non-legitimate ZIP or plugin files. If you suspect engagement, change the wp-config.php jump keys, restore from clean backups and consider a forensic audit. Enable 2FA and limit the use of accounts with high privileges reduces the social engineering operating window.

Finally, keep backup off the production server and activate automatic updates when possible; WordPress indicates that sites with background updates should receive the release automatically. Since the complete operation described by pwn.ai requires additional interaction with an administrator, the immediate patch combination, login access controls and strong operational security practices is the most effective defence.

The finding illustrates how apparently presenting vulnerabilities (XSS on an error page) can become critical vectors when interacting with existing logic and APIs from the same site. The technical and practical recommendation is unequivocal: implement the official update without delay and review exposed administrators and credentials.