WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.
DISPUTED wp-admin/setup-config.php in the installation component in WordPress 3.3.1 and earlier does not ensure that the specified MySQL database service is appropriate, which allows remote attackers to configure an arbitrary database via the dbhost and dbname parameters, and subsequently conduct static code injection and cross-site scripting (XSS) attacks via (1) an HTTP request or (2) a MySQL query. NOTE: the vendor disputes the significance of this issue; however, remote code execution makes the issue important in many realistic environments.
WordPress Core, in versions up to 6.0.2, is vulnerable to Authenticated Stored Cross-Site Scripting that can be exploited by users with access to the WordPress post and page editor, typically consisting of Authors, Contributors, and Editors making it possible to inject arbitrary web scripts into posts and pages that execute if the themeta(); function is called on that page.
Improper authentication vulnerability in WordPress versions prior to 6.0.3 allows a remote unauthenticated attacker to obtain the email address of the user who posted a blog using the WordPress Post by Email Feature. The developer also provides new patched releases for all versions since 3.7.
WordPress is affected by an unauthenticated blind SSRF in the pingback feature. Because of a TOCTOU race condition between the validation checks and the HTTP request, attackers can reach internal hosts that are explicitly forbidden.
Cross-site scripting vulnerability in WordPress versions prior to 6.0.3 allows a remote unauthenticated attacker to inject an arbitrary script. The developer also provides new patched releases for all versions since 3.7.
Cross-site scripting vulnerability in WordPress versions prior to 6.0.3 allows a remote unauthenticated attacker to inject an arbitrary script. The developer also provides new patched releases for all versions since 3.7.
WordPress is a free and open-source content management system written in PHP and paired with a MariaDB database. Low-privileged authenticated users (like author) in WordPress core are able to execute JavaScript/perform stored XSS attack, which can affect high-privileged users. This has been patched in WordPress version 5.8.3. Older affected versions are also fixed via security release, that go back till 3.7.37. We strongly recommend that you keep auto-updates enabled. There are no known workarounds for this issue.
WordPress is a free and open-source content management system written in PHP and paired with a MariaDB database. On a multisite, users with Super Admin role can bypass explicit/additional hardening under certain conditions through object injection. This has been patched in WordPress version 5.8.3. Older affected versions are also fixed via security release, that go back till 3.7.37. We strongly recommend that you keep auto-updates enabled. There are no known workarounds for this issue.
This vulnerability allows remote attackers to disclose sensitive information on affected installations of WordPress Core. Authentication is not required to exploit this vulnerability. The specific flaw exists within the WPQuery class. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to disclose stored credentials, leading to further compromise.
WordPress is a free and open-source content management system written in PHP and paired with a MariaDB database. Due to lack of proper sanitization in one of the classes, there's potential for unintended SQL queries to be executed. This has been patched in WordPress version 5.8.3. Older affected versions are also fixed via security release, that go back till 4.1.34. We strongly recommend that you keep auto-updates enabled. There are no known workarounds for this issue.
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 an open publishing platform for the Web. Unserialization of instances of the WPHTMLToken class allows for code execution via its destruct() magic method. This issue was fixed in WordPress 6.4.2 on December 6th, 2023. Versions prior to 6.4.0 are not affected.
This vulnerability allows remote attackers to execute arbitrary code on affected installations of WordPress Core. Authentication may be required to exploit this vulnerability, depending on the product configuration. The specific flaw exists within the maybeunserialize function. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the service account.
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.
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.
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.
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.
Exposure of Sensitive Information to an Unauthorized Actor in WordPress from 6.3 through 6.3.1, from 6.2 through 6.2.2, from 6.1 through 6.13, from 6.0 through 6.0.5, from 5.9 through 5.9.7, from 5.8 through 5.8.7, from 5.7 through 5.7.9, from 5.6 through 5.6.11, from 5.5 through 5.5.12, from 5.4 through 5.4.13, from 5.3 through 5.3.15, from 5.2 through 5.2.18, from 5.1 through 5.1.16, from 5.0 through 5.0.19, from 4.9 through 4.9.23, from 4.8 through 4.8.22, from 4.7 through 4.7.26, from 4.6 through 4.6.26, from 4.5 through 4.5.29, from 4.4 through 4.4.30, from 4.3 through 4.3.31, from 4.2 through 4.2.35, from 4.1 through 4.1.38.
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 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?
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.