WordPress released version 7.0.3 on Tuesday, a security update that patches twelve distinct vulnerabilities in the core software. Among them is a reflected cross-site scripting (XSS) flaw on the login screen rated 8.9 out of 10 in severity, a score that places it firmly in the high-risk category and signals a significant threat to site security. The update arrives just weeks after the high-profile WP2Shell vulnerability dominated security headlines, suggesting that the pace of core vulnerability discovery is accelerating, driven in part by the increasing use of artificial intelligence tools in penetration testing.
The Twelve Vulnerabilities Patched in WordPress 7.0.3
The official WordPress announcement provided only the barest outline of each issue, omitting severity ratings or detailed technical descriptions. This lack of transparency makes it difficult for site administrators to assess the real-world risk posed by each flaw. Based on the available descriptions, the twelve vulnerabilities addressed in this release are:
- A Contributor+ stored cross-site scripting (XSS) issue in the Post Date block
- A Contributor+ stored cross-site scripting (XSS) issue in the Post Content block
- An information disclosure issue in the Latest Comments block exposing comments on password-protected posts
- A bypass of the email address confirmation flow
- An Author+ CSS injection issue via a bypass of the safe CSS attribute filter
- A Contributor+ stored cross-site scripting (XSS) issue in posts via the emoji settings element
- A privilege escalation issue on multisite networks with user registration enabled, allowing a user to create a new site
- A server-side request forgery (SSRF) issue in URL validation allowing requests to link-local ranges
- A pre-auth reflected cross-site scripting (XSS) issue on the login screen with potential to lead to PHP code execution
- A disclosure of notes in comment feeds
- An enumeration of post slugs
- A Contributor+ stored cross-site scripting (XSS) issue in Quick Edit on sites with a large number of users
Three of these vulnerabilities stand out as particularly concerning based on their potential impact and the limited information provided.
The Pre-Auth XSS Vulnerability: 8.9/10 Severity
The most dangerous vulnerability in this batch is the pre-auth reflected XSS issue on the login screen. The Open Worldwide Application Security Project (OWASP) defines cross-site scripting as an injection attack in which malicious scripts are inserted into otherwise benign and trusted websites. When a user’s browser executes that script, believing it came from a trusted source, the attacker can access cookies, session tokens, and other sensitive information stored by the browser for that site.
What makes this particular vulnerability especially alarming is that it carries the potential for remote code execution (RCE). The official WordPress GitHub security advisory explains that via a specially crafted malicious third-party website hosted by an attacker, it is possible for the XSS to be escalated to an RCE vulnerability, though this escalation requires conditions outside the attacker’s control. Successful exploitation also demands social engineering and explicit interaction by the target victim.
The severity rating of 8.9/10 reflects the serious potential for damage, even though the attack is not trivially automatable. The pre-auth designation means an attacker does not need a WordPress account to initiate the attack, which lowers the barrier to entry. However, requiring a logged-in user to perform a specific action gives site administrators a window to educate users about phishing risks.
Oliver Sild of Patchstack commented on X that the social engineering component likely reduces the attractiveness of this vulnerability for mass exploitation. Patchstack customers received mitigation rules at the time of disclosure, and Sild confirmed that Patchstack is actively monitoring for exploitation attempts. Early indications suggest that hackers have not shown significant interest in the XSS-to-RCE chain, possibly because the social engineering requirement makes it less reliable for automated attacks.
SSRF Vulnerability: Requests to Link-Local Ranges
The server-side request forgery (SSRF) issue in URL validation allows requests to link-local IP ranges. SSRF attacks occur when an attacker can induce the server to make requests to internal resources that are not intended to be accessible from the outside. In this context, link-local IP addresses are reserved for internal communication within a server or local network. The minimal description of this vulnerability suggests that an attacker could use the WordPress installation as a proxy to probe or interact with internal services running on the same host or adjacent systems.
Without a detailed disclosure, it is difficult to assess the full scope of this vulnerability. SSRF flaws can be leveraged for port scanning, accessing cloud metadata endpoints, or exploiting internal applications that trust traffic originating from the WordPress server. The fix for this issue is included in version 7.0.3, and administrators running WordPress on cloud infrastructure or in environments with sensitive internal services should prioritize this update.
Privilege Escalation on Multisite Networks
The privilege escalation issue affects multisite networks where user registration is enabled. The vulnerability allows a user to create a new site on the network, an action that should normally require elevated privileges. This is particularly relevant for universities, large organizations, and hosting providers that operate WordPress multisite installations. An unprivileged user could potentially create unauthorized sites, which could be used for phishing, spam distribution, or other malicious activities under the same domain.
Multisite administrators should verify that user registration is configured with appropriate restrictions and that site creation capabilities are limited to trusted roles. The update to 7.0.3 resolves this issue, but site owners should also review their user role configurations as a defensive measure.
How Did These Vulnerabilities Get Discovered?
The disclosures in this release were reported by multiple security firms, including Anthropic AI, pwn_ai, and Aikido Security. The involvement of AI-driven security testing tools reflects a broader trend in vulnerability research. Oliver Sild noted that after the WP2Shell vulnerability and the credit awarded to OpenAI Sol Ultra, many labs and AI penetration testing companies rushed to demonstrate that they could also find significant issues in WordPress core. The result is this unusually large batch of twelve vulnerabilities patched in a single release.
Historically, WordPress core has been relatively resistant to vulnerability discoveries. The software undergoes extensive review, and its widespread deployment makes it a high-value target for security researchers. The recent cluster of findings, aided by AI, suggests that the security landscape for WordPress is evolving. Automated code analysis, fuzzing, and AI-assisted pattern recognition are uncovering edge cases and logic flaws that traditional manual auditing might miss.
What Do These Vulnerabilities Mean for WordPress Users?
For the average WordPress site owner, the critical takeaway is straightforward: update to version 7.0.3 immediately. WordPress includes automatic background updates for security releases, so many sites will already receive the fix without manual intervention. However, site administrators who have disabled automatic updates, or who manage sites with custom update schedules, should verify their update status.
The vulnerabilities affect all versions of WordPress. The fix has been backported to all branches back to version 4.7, ensuring that even sites running older but still supported versions can receive the patch. This broad backporting is a courtesy extended by the WordPress security team to maintain coverage across the ecosystem.
Site owners should also consider the broader implications. The pre-auth XSS vulnerability, while requiring user interaction, underscores the importance of user education and phishing awareness. Even the most technically secure site can be compromised if an administrative user is tricked into performing a malicious action.
How Does This Compare to the WP2Shell Vulnerability?
The WP2Shell vulnerability, which received widespread attention in the weeks before this release, was a distinct type of flaw. WP2Shell was a remote code execution vulnerability that could be exploited directly without user interaction, making it significantly more dangerous for mass exploitation. The vulnerabilities patched in 7.0.3, by contrast, generally require some level of user interaction or specific configuration conditions to be fully exploited. Sild characterized this difference by noting that none of the vulnerabilities in this batch are “mass-exploitable like WP2Shell.”
This distinction matters for prioritization. Site administrators who delay updates risk exposure, but the immediate danger of automated exploitation is lower than it was for WP2Shell. Nevertheless, the cumulative risk across twelve vulnerabilities means that procrastination is ill-advised.
Should You Be Worried About Stored XSS Vulnerabilities?
Multiple vulnerabilities in this release are classified as stored cross-site scripting (XSS) issues. Stored XSS occurs when malicious script is permanently stored on the server, such as in a post or comment, and then delivered to every user who views that content. In WordPress, these vulnerabilities are typically limited to users with Contributor-level access or higher. This means that an attacker would first need to obtain or compromise an account with posting privileges.
For most WordPress sites, the user base with Contributor access is small and trusted. However, sites that allow open registration or that have many authors should take note. The Quick Edit vulnerability, which applies specifically to sites with a large number of users, suggests that performance optimizations or user management features introduced complexity that created a security gap.
What Is the Risk from Information Disclosure Vulnerabilities?
The disclosure of comments on password-protected posts and the enumeration of post slugs are lower-severity issues, but they still warrant attention. Information disclosure can feed into larger attack chains. Knowing the existence and structure of password-protected content might help an attacker target their efforts. Similarly, being able to enumerate post slugs can reveal site structure and content patterns.
The disclosure of notes in comment feeds is a separate issue that could leak internal comments or annotations that were not intended for public view. Site owners using comment feeds should verify that their feeds are properly configured and that sensitive notes are not inadvertently exposed.
What Should You Do Right Now?
The most important action is to confirm that your WordPress installation has updated to version 7.0.3. Check your WordPress admin dashboard for the current version number. If automatic updates are enabled and your server configuration supports them, the update should have been applied already. If not, initiate the update manually through the dashboard or using WP-CLI.
Review your user roles and permissions, particularly if you operate a multisite network or allow user registration. Remove any unnecessary accounts that have posting privileges. Educate users with elevated access about the risks of phishing and social engineering attacks, especially those that might originate from third-party websites.
Consider implementing a Web Application Firewall (WAF) or using a security plugin that can provide virtual patching for vulnerabilities that have been disclosed but not yet patched on your site. Patchstack, for example, provided mitigation rules to its customers at the time of disclosure, offering protection before the official update was available.
The Growing Role of AI in WordPress Security Research
The involvement of AI companies in reporting these vulnerabilities marks a shift in the security research ecosystem. Traditional vulnerability research relied heavily on manual code review, fuzzing, and the intuition of experienced researchers. AI-assisted tools, particularly large language models and automated program analysis systems, can scan codebases at scale and identify patterns that human reviewers might overlook.
This trend brings both benefits and challenges. On the positive side, more vulnerabilities are being discovered and patched before malicious actors find and exploit them. The WordPress security team has a strong track record of responding quickly to responsible disclosures. On the challenging side, the volume of disclosures is increasing, and each release requires careful triage. Site administrators face a growing need to stay current with updates.
The fact that multiple AI security firms submitted findings for this release suggests that WordPress core is being subjected to unprecedented scrutiny. This is ultimately good for the health of the ecosystem, but it also means that the pace of security updates may accelerate. Site owners should establish processes for rapid deployment of security patches, even if they prefer to test major updates more cautiously.
WordPress remains one of the most widely used content management systems in the world, powering over 40% of all websites. Its security posture directly affects a significant portion of the internet. The 7.0.3 release demonstrates that while the software is robust, it is not immune to vulnerabilities. The combination of AI-driven discovery, transparent disclosure practices, and rapid patching by the WordPress team creates a security model that, while imperfect, is responsive and effective. Site owners who prioritize updates and maintain awareness of the evolving threat landscape will remain well-protected as the tools and techniques used by both researchers and attackers continue to advance.
