An unauthenticated attacker can make getpagetemplate() page-template resolution include a chosen readable local .php file outside the active theme directories. If relevant pre-conditions for both the server and the active theme are met, this can lead to RCE.

WordPress is vulnerable to a remote code execution vulnerability via malicious Postscript file upload by an Author level user or higher.

Prerequisites: Imagick and Ghostscript in use on the server A malicious user with the uploadfiles capability

This issue affects all versions of WordPress. Version 7.0.4 has been released, containing a fix for the vulnerability, and as a courtesy to users on older branches the fix has been backported to all branches back to 4.7.

I spent some time this weekend reproducing the recently disclosed XSS2Shell: WordPress login-page reflected XSS (CVE-2026-64638). If you didn’t get a chance to read about it, here is the summary: Crazy simple XSS where the root cause is two sanitizers that disagree about what counts as an HTML tag:

<b>test</b> gets stripped, while < b>test< /b> passes through the first sanitizer and is normalized into a valid <b> element by the second.

That gives you an HTML injection, but you can’t turn it into XSS because the second sanitizer has an allowlist and only allows specific HTML tags and attributes. The rest of the chain uses JavaScript already loaded on the login page, DOM clobbering, and a JSONP response to reach script execution in the login page. It’s a creative chain, although much simpler than the WP2Shell chain from two weeks ago. IMO the “2Shell” part from the title is a bit of a stretch. The original write-up continues after triggering the XSS to show how you can get a RCE (basically by targeting an admin account to open your XSS which uploads a shell as a plugin). I agree this can be abused at scale given how widely used WP is, but it’s a phishing-shaped precondition rather than “send one request, get a shell” as we’ve seen in WP2Shell. It’s a cool bug anyway.

I turned my reproduction into a guided lab for anyone who wants to work through the chain rather than only read the write-up.

Link: https://learn.uphack.io/lab/xss2shell-wordpress-login-xss/

Feedback on the lab or the technical explanation is very welcome.

WordPress is vulnerable to a pre-auth reflected XSS vulnerability on the login screen. Via a specially crafted malicious third-party website hosted by an attacker, it is possible for this to be escalated to an RCE vulnerability with conditions outside of the attackers control. This requires successful social engineering of and explicit interaction by the target victim. This issue affects all versions of WordPress. Version 7.0.3 has been released, containing a fix for the vulnerability, and as a courtesy to users on older branches the fix has been backported to all branches back to 4.7. Discovered and responsibly disclosed by the team at pwn.ai.

Hi everyone,

A high-severity security issue was recently fixed in WordPress 7.0.3 (and backported to older versions). The vulnerability, tracked as CVE-2026-64638, is a pre-authentication reflected XSS flaw on the login page, discovered by the team at pwn.ai. Under specific conditions, if an administrator clicks a malicious link, it could potentially lead to PHP code execution.

Given how widely WordPress is used across enterprise environments, this is definitely something sysadmins and security teams should keep on their radar.

Source / Read more here:https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html

Are you relying on automatic background updates for this, or manually patching across your environments? How are your WAFs handling login page traffic?

When the WP2Shell writeup came out recently (unauth RCE in WordPress core, CVE-2026-63030 + CVE-2026-60137), I read it a few times and still couldn't really understand the whole chain in my head. I personally don’t have a lot of experience with WP internals, so I had a lot of “whys” when reading it. The way I usually deal with that is to just try to reproduce the thing to see how it works.

I then turned it into a full lab that has a WordPress 7.0.1 app and steps through the entire chain from an unauthenticated request to RCE.

Honestly it was more work than I expected. The SQL injection is read-only, so a good amount of the exploiting part is dedicated to finding a way to turn that SQLi into an actual write. It uses a bunch of WP legitimate features that I had no idea about, so reproducing each hop reliably took a while.

I built it mostly for my own understanding, but made it available for free in case anyone else is struggling to understand the middle part of the exploit. Original research is Adam Kues at Searchlight Cyber, I recommend reading his article if you haven't done so already.

Link to the lab (it doesn’t work on mobile, you’ll need a desktop device): https://learn.uphack.io/lab/wp2shell-wordpress-rce

When the WP2Shell writeup came out recently (unauth RCE in WordPress core, CVE-2026-63030 + CVE-2026-60137), I read it a few times and still couldn't really understand the whole chain in my head. I personally don’t have a lot of experience with WP internals, so I had a lot of “whys” when reading it. The way I usually deal with that is to just try to reproduce the thing to see how it works.

I then turned it into a full lab that has a WordPress 7.0.1 app and steps through the entire chain from an unauthenticated request to RCE.

Honestly it was more work than I expected. The SQL injection is read-only, so a good amount of the exploiting part is dedicated to finding a way to turn that SQLi into an actual write. It uses a bunch of WP legitimate features that I had no idea about, so reproducing each hop reliably took a while.

I built it mostly for my own understanding, but made it available for free in case anyone else is struggling to understand the middle part of the exploit. Original research is Adam Kues at Searchlight Cyber, I recommend reading his article if you haven't done so already.

Link to the lab (it doesn’t work on mobile, you’ll need a desktop device): https://learn.uphack.io/lab/wp2shell-wordpress-rce

Exploitation of the new WordPress vulnerabilities tracked as CVE-2026-60137 and CVE-2026-63030 started soon after disclosure.

https://www.securityweek.com/wp2shell-wordpress-vulnerabilities-exploited-in-the-wild/

Follow-up on the WordPress core pre-auth RCE. Searchlight Cyber held technical details at disclosure and Rapid7 predicted a PoC would land fast. It has.

What's new:

A working exploit is now public on GitHub, MIT-licensed with an "educational / authorized testing only" disclaimer, and being mirrored on a Telegram channel (bundled with target-discovery dorks). Free, not paywalled. Chain recap: CVE-2026-63030 (REST batch-route confusion → auth bypass) unlocks CVE-2026-60137 (SQLi in WPQuery authornotin) → dump DB → crack admin hash → admin = RCE on a stock install via the theme editor. No plugins, no auth. Affected: 6.9.0–6.9.4, 7.0.0–7.0.1 (RCE chain); SQLi reaches into 6.8.x. Fixed in 7.0.2 / 6.9.5 / 6.8.6, forced auto-updates enabled.

If you're patched you're fine. For any long tail of internet-facing WP, assume opportunistic scanning is starting now that a working exploit is public, and treat post-disclosure exposure as potential compromise (rogue admins, modified PHP, new files in uploads).

Disclosure: I write for Ransomnews.

WordPress 6.9.x before 6.9.5 and 7.0.x before 7.0.2 is affected by a REST API batch endpoint route confusion issue which, combined with the authornotin WPQuery SQL Injection (CVE-2026-60137), could allow an attacker to perform SQL Injection and achieve Remote Code Execution.

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the authornotin parameter of WPQuery, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.

The DHL eCommerce (Benelux) for WooCommerce plugin for WordPress is vulnerable to unauthorized modification and loss of data due to a missing capability check and missing nonce verification on the createlabel() and deletelabel() functions in versions up to, and including, 2.2.3. These functions are wired to the wpajaxdhlpwclabelcreate and wpajaxdhlpwclabeldelete hooks and act on an attacker-supplied postid (WooCommerce order ID). This makes it possible for authenticated attackers, with Subscriber-level access and above, to create or delete DHL shipping labels associated with any WooCommerce order on the site.

WordPress core is vulnerable to unauthorized access in versions 6.9 through 6.9.1. The Notes feature (block-level collaboration annotations) was introduced in WordPress 6.9 to allow editorial comments directly on posts in the block editor. However, the REST API createitempermissionscheck() method in the comments controller did not verify that the authenticated user has editpost permission on the target post when creating a note. This makes it possible for authenticated attackers with Subscriber-level access to create notes on any post, including posts authored by other users, private posts, and posts in any status.

The CSV to SortTable plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'csv' shortcode in all versions up to, and including, 4.2 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Admin and Customer Messages After Order for WooCommerce: OrderConvo WordPress plugin before 14 does not validate the path of files to be downloaded, which could allow unauthenticated attacker to read/download arbitrary files via a path traversal attack

The Zephyr Project Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via admin settings in all versions up to, and including, 3.3.202 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with administrator-level permissions and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This only affects multi-site installations and installations where unfilteredhtml has been disabled.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in WordPress allows Stored XSS. WordPress core security team is aware of the issue and working on a fix. This is low severity vulnerability that requires an attacker to have Author or higher user privileges to execute the attack vector.This issue affects WordPress: from 6.8 through 6.8.2, from 6.7 through 6.7.3, from 6.6 through 6.6.3, from 6.5 through 6.5.6, from 6.4 through 6.4.6, from 6.3 through 6.3.6, from 6.2 through 6.2.7, from 6.1 through 6.1.8, from 6.0 through 6.0.10, from 5.9 through 5.9.11, from 5.8 through 5.8.11, from 5.7 through 5.7.13, from 5.6 through 5.6.15, from 5.5 through 5.5.16, from 5.4 through 5.4.17, from 5.3 through 5.3.19, from 5.2 through 5.2.22, from 5.1 through 5.1.20, from 5.0 through 5.0.23, from 4.9 through 4.9.27, from 4.8 through 4.8.26, from 4.7 through 4.7.30.

Insertion of Sensitive Information Into Sent Data vulnerability in WordPress allows Retrieve Embedded Sensitive Data. The WordPress Core security team is aware of the issue and is already working on a fix. This is a low-severity vulnerability. Contributor-level privileges required in order to exploit it. This issue affects WordPress: from 6.8 through 6.8.2, from 6.7 through 6.7.3, from 6.6 through 6.6.3, from 6.5 through 6.5.6, from 6.4 through 6.4.6, from 6.3 through 6.3.6, from 6.2 through 6.2.7, from 6.1 through 6.1.8, from 6.0 through 6.0.10, from 5.9 through 5.9.11, from 5.8 through 5.8.11, from 5.7 through 5.7.13, from 5.6 through 5.6.15, from 5.5 through 5.5.16, from 5.4 through 5.4.17, from 5.3 through 5.3.19, from 5.2 through 5.2.22, from 5.1 through 5.1.20, from 5.0 through 5.0.23, from 4.9 through 4.9.27, from 4.8 through 4.8.26, from 4.7 through 4.7.30.

The Html Social share buttons plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'zmshbtn' shortcode in all versions up to, and including, 2.1.16 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Vibes plugin for WordPress is vulnerable to time-based SQL Injection via the ‘resource’ parameter in all versions up to, and including, 2.2.0 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

The bSecure plugin for WordPress is vulnerable to Privilege Escalation due to missing authorization within its orderinfo REST endpoint in versions 1.3.7 through 1.7.9. The plugin registers the /webhook/v2/orderinfo/ route with a permissioncallback that always returns true, effectively bypassing all authentication. This makes it possible for unauthenticated attackers who know any user’s email to obtain a valid login cookie and fully impersonate that account.

The Wise Chat plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the X-Forwarded-For header in all versions up to, and including, 3.3.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The Directory Listings WordPress plugin – uListing plugin for WordPress is vulnerable to unauthorized modification of data and PHP Object Injection due to a missing capability check on the stmlistingajax AJAX action in all versions up to, and including, 2.2.0. This makes it possible for authenticated attackers, with subscriber-level access and above, to update post meta data and inject PHP Objects that may be unserialized. A capability check was added in 2.1.8, but the unserialize is still present.

The Ziggeo plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'ziggeoevent' shortcode in all versions up to, and including, 3.1 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The UMich OIDC Login plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'umichoidcbutton' shortcode in all versions up to, and including, 1.2.0 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

The MagicForm plugin for WordPress is vulnerable to access and modification of data due to a missing capability check on the plugin's AJAX actions in all versions up to, and including, 1.6.2. This makes it possible for authenticated attackers, with Subscriber-level access and above, to invoke those actions in order to delete or view logs, modify forms or modify plugin settings.

The Bilingual Linker plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the blotherlanglink1 parameter in all versions up to, and including, 2.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.