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.
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.
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?
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.
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
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.
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.
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.
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 Post Grid Gutenberg Blocks and WordPress Blog Plugin – PostX plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the 'postxpresetscallback' function in all versions up to, and including, 4.1.2. This makes it possible for authenticated attackers, with Contributor-level access and above, to change arbitrary options on affected sites. This can be used to enable new user registration and set the default role for new users to Administrator.
The Reviews and Rating – Google Reviews plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's file upload feature in all versions up to, and including, 5.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
The Post Grid Gutenberg Blocks and WordPress Blog Plugin – PostX plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's file uploading feature in all versions up to, and including, 4.1.1 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
The Hash Elements plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'url' parameter within multiple widgets in all versions up to, and including, 1.3.8 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.
WordPress Core is vulnerable to Stored Cross-Site Scripting via user display names in the Avatar block in various versions up to 6.5.2 due to insufficient output escaping on the display name. 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. In addition, it also makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that have the comment block present and display the comment author's avatar.
WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. ### Impact The issue allows an authenticated but low-privileged user (like contributor/author) to execute XSS in the editor. This bypasses the restrictions imposed on users who do not have the permission to post unfilteredhtml. ### Patches This has been patched in WordPress 5.8, and will be pushed to older versions via minor releases (automatic updates). It's strongly recommended that you keep auto-updates enabled to receive the fix. ### References https://wordpress.org/news/category/releases/ https://hackerone.com/reports/1142140 ### For more information If you have any questions or comments about this advisory: Open an issue in HackerOne
WordPress is a free and open-source content management system written in PHP and paired with a MySQL or MariaDB database. In affected versions output data of the function wpdie() can be leaked under certain conditions, which can include data like nonces. It can then be used to perform actions on your behalf. This has been patched in WordPress 5.8.1, along with any older affected versions via minor releases. It's strongly recommended that you keep auto-updates enabled to receive the fix.
In WordPress before 4.7.3 (wp-admin/plugins.php), unintended files can be deleted by administrators using the plugin deletion functionality.
In WordPress before 4.7.3, there is authenticated Cross-Site Scripting (XSS) via Media File Metadata. This is demonstrated by both (1) mishandling of the playlist shortcode in the wpplaylistshortcode function in wp-includes/media.php and (2) mishandling of meta information in the renderTracks function in wp-includes/js/mediaelement/wp-playlist.js.
In WordPress before 4.7.3 (wp-includes/pluggable.php), control characters can trick redirect URL validation.
In WordPress before 4.7.3 (wp-includes/embed.php), there is authenticated Cross-Site Scripting (XSS) in YouTube URL Embeds.
SQL injection vulnerability in wp-includes/class-wp-query.php in WPQuery in WordPress before 4.7.2 allows remote attackers to execute arbitrary SQL commands by leveraging the presence of an affected plugin or theme that mishandles a crafted post type name.
Cross-site scripting (XSS) vulnerability in wp-admin/includes/class-wp-posts-list-table.php in the posts list table in WordPress before 4.7.2 allows remote attackers to inject arbitrary web script or HTML via a crafted excerpt.
wp-admin/includes/class-wp-press-this.php in Press This in WordPress before 4.7.2 does not properly restrict visibility of a taxonomy-assignment user interface, which allows remote attackers to bypass intended access restrictions by reading terms.
Impact The mailSend function in the default isMail transport in PHPMailer before 5.2.18 might allow remote attackers to pass extra parameters to the mail command and consequently execute arbitrary code via a \" (backslash double quote) in a crafted Sender property.
Patches Fixed in 5.2.18
Workarounds Filter and validate user input before passing it to internal functions.
References https://nvd.nist.gov/vuln/detail/CVE-2016-10033 Related to a follow-on issue in https://nvd.nist.gov/vuln/detail/CVE-2016-10045
For more information If you have any questions or comments about this advisory: Open a private issue in the PHPMailer project
Multiple cross-site scripting (XSS) vulnerabilities in the Thank You Counter Button plugin 1.8.7 for WordPress allow remote attackers to inject arbitrary web script or HTML via the (1) thankscaption, (2) thankscaptionstyle, or (3) thanksstyle parameter to wp-admin/options.php.
SQL injection vulnerability in sesearchdefault in the Search Everything plugin before 7.0.3 for WordPress allows remote attackers to execute arbitrary SQL commands via the s parameter to index.php. NOTE: some of these details are obtained from third party information.