WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed

WordPress 7.0.3 landed on 6 August 2026. It’s a security release with 12 different fixes covering pre-auth cross-site scripting (XSS), stored XSS, privilege escalation, information disclosure, CSS injection, an email verification bypass, and server-side request forgery.

Patchstack deployed RapidMitigate rules for the high-risk vulnerabilities immediately. We still recommend updating to the most recent version of WordPress available.

The Vulnerabilities

Unauthenticated Reflected XSS to Remote Code Execution

The headline vulnerability is a reflected XSS on the login screen, reachable without any authentication and with the potential to lead to PHP code execution (CVE-2026-64638, reported by the pwn.ai team).

While this is definitely a vulnerability worth monitoring, it’s worth being precise about what “potential PHP code execution” actually requires. Reflected XSS only fires in the browser of whoever clicks the crafted link; it doesn’t spread on its own the way stored XSS does. That makes this a targeted send, not a drive-by. The attacker needs one specific person, on this specific site, to click one specific URL. If that person isn’t an Administrator, the payload does nothing useful.

If an Administrator does click the targeted link and trigger the Reflected XSS attack, this can lead to a full RCE. The attacker is able to use specially crafted JavaScript to essentially take over the Admin’s session, including the ability to load custom code or plugins onto the site. For this to trigger though, the Administrator would need to be successfully phished and lead to click the dangerous link.

Stored XSS: Four Researchers, Four Vulnerabilities, Two Commonalities

The next four issues all need Contributor-level access. For sites with a pretty select group of writers, this isn’t as impactful as an unauthenticated attack can be, but any site with guest authors, freelance writers, or content agencies should be aware of these, as that’s exactly the level of access you’re likely giving out.

• Stored XSS in posts via the emoji settings element (Asaf Mozes)
• Stored XSS in the Post Content block (n05ec)
• Stored XSS in the Quick Edit on sites with a large number of users (Naveen S and Ajmal Moochingal)
• Stored XSS in the Post Date block (Alex Concha)

Four separate researchers landed on four separate bugs for the same privilege level during the same release cycle. Site owners should take this as a good sign to audit who they’re giving access to, and especially site owners with large numbers of Contributors should make sure to update immediately.

Multisite Privilege Escalation

WordPress Multisite networks with user registration turned on have a privilege escalation bug that lets registered users create sites they have no business creating (reported by Aikido Security). This only impacts Multisite installations; regular single-site WordPress installations can ignore this one.

Information Disclosure, Three Ways

None of these vulnerabilities are handing over the keys to your WordPress site, but all three can give an attacker something: the Latest Comments block can leak comments from password-protected posts; post slugs can be enumerated (HDWSec); and comment feeds can disclose notes that were supposed to stay private (Elio Gubser). These aren’t getting an attacker into your Admin Dashboard, but they’re all leaking data a site may have private for a reason.

CSS Injection, Email Bypass, SSRF

The rest of the release: an Author+ bypass of the safe CSS attribute filter (reported by Anthropic), a way around the email address confirmation flow (0ways), and a server-side request forgery bug in URL validation that reaches link-local address ranges (Andrew Mohawk and others). Especially for site owners running their site themselves, the SSRF is worth updating over; it’s the first step in an attacker going from “just your WordPress site” to “digging around in your internal network.”

Who’s Finding These Vulnerabilities Has Changed

Back up to 7.0.2, the release before this one. The vulnerability chain patched there (CVE-2026-60137 and CVE-2026-63030, the wp2shell exploit) wasn’t found by a person combing through the batch API line by line. Searchlight Cyber ran OpenAI’s GPT-5.6 Sol Ultra model against WordPress Core and had a working pre-auth SQL injection, chained all the way to remote code execution, in ten hours. Total cost: about $25.

Now look at 7.0.3. The XSS->RCE vulnerability and the Author+ CSS injection are both credited to companies focused on AI: pwn.ai and their “autonomous pentesting” for one, and Anthropic directly for the other.

That’s the shift worth looking at. A few months ago, AI-assisted research meant a human researcher with a model as a very fast assistant. Now the model finds the vulnerability, can take their finding all the way to exploitation, and all the researcher needs to do is report it. The chart below shows what that’s done to WordPress’s HackerOne intake: nine years of monthly reports in the dozens, with report count picking up this spring, leading to 450 reports in July.

This lines up with more advanced models, like the aforementioned GPT-5.6 Sol, coming into widespread use for security research.

None of that is bad news on its own; more eyes on the codebase, faster, is a good thing for WordPress and other open source projects long-term. But it does mean old assumptions about the speed of finding vulnerabilities (and the speed to exploit them) doesn’t hold anymore. If a model can go from zero to working RCE in ten hours, the disclosure-to-exploit window isn’t measured in days, it’s measured in hours.

Update to 7.0.3 today regardless. But if research is moving this fast, “we’ll patch it during a maintenance window” is a plan built for a threat landscape that’s already gone.