WordPress Core Flaws Are Being Exploited: Which Versions Need an Update

Two WordPress vulnerabilities are now known to be exploited in real attacks. Both affect Core, and site owners running the 7.0, 6.9, or 6.8 branches should check the exact installed version and apply the relevant security update instead of waiting for the next maintenance window.

On July 17, the WordPress team released WordPress 7.0.2, along with security backports 6.9.5 and 6.8.6. The release fixes two related security issues. Because of their severity, WordPress enabled forced background updates for affected installations. That does not guarantee every site updated successfully: file permissions, hosting configuration, or disabled updates can still stop the process.

Why the warning is now urgent

On July 21, the U.S. Cybersecurity and Infrastructure Security Agency added both flaws to its Known Exploited Vulnerabilities catalog. A KEV entry means CISA has evidence of exploitation. It does not mean every WordPress site has been compromised, and CISA has not named a victim count, a specific threat group, or confirmed ransomware use for these entries.

For U.S. federal civilian agencies, CISA set remediation due dates of July 24 for CVE-2026-63030 and August 4 for CVE-2026-60137. These are federal operational deadlines, not a universal legal deadline for private site owners.

What CVE-2026-60137 and CVE-2026-63030 do

CVE-2026-60137 concerns the author__not_in parameter in WP_Query. WordPress Core did not sanitize the value correctly, which could enable SQL injection when a plugin or theme passed untrusted input into that parameter. The condition matters: simply running WordPress 6.8 did not automatically give every visitor remote code execution.

CVE-2026-63030 is a route-handling conflict in the REST API batch endpoint. On WordPress 6.9 and 7.0, it can be chained with the first flaw to bypass expected parameter validation, perform SQL injection, and ultimately achieve remote code execution. The two-flaw chain creates the most dangerous scenario. WordPress 6.8 is affected by CVE-2026-60137, but not by CVE-2026-63030.

Which WordPress versions need an update

Installed version	Affected by	Minimum fixed version
7.0.0–7.0.1	Both CVEs	7.0.2
6.9.0–6.9.4	Both CVEs	6.9.5
6.8.0–6.8.5	CVE-2026-60137 only	6.8.6
Earlier than 6.8	Not affected by these two CVEs specifically	Move to a current supported release

“Not affected by these two CVEs” does not make an older branch safe. WordPress notes that only the latest release is actively supported. If a major-version upgrade needs compatibility testing, install the security backport for your current branch immediately, then schedule a controlled move to the current release.

What site owners should do now

1. Confirm the version. Open Dashboard → Updates in WordPress Admin. If WP-CLI is available, run wp core version. Do not rely only on a hosting email or an automatic-update notification.
2. Create and verify a backup. Save both the database and site files, make sure the archive opens, and keep a copy away from the server. For a durable setup, follow the 3-2-1 backup rule.
3. Update WordPress Core. Install 7.0.2 for the 7.0 branch, 6.9.5 for 6.9, or 6.8.6 for 6.8. A security plugin or web application firewall rule is not a substitute for the vendor’s Core patch.
4. Update plugins and themes. The first CVE depends on how an extension supplies data to WP_Query. Patched Core closes the described flaw, but it does not fix unrelated vulnerabilities in outdated extensions.
5. Verify the result. Return to the Updates screen, then test the homepage, login, forms, and other critical functions. Clear caches afterward so visitors receive the current files.
6. Check Core file integrity. The wp core verify-checksums command compares installed Core files with WordPress.org checksums before WordPress loads. A mismatch needs investigation, but this command does not scan the database, wp-content, or uploaded files.

What to review after a period of exposure

If the site remained on an affected version, installing the patch cannot prove that no earlier compromise occurred. Review web-server and security logs for unusual REST API batch requests, inspect the administrator list, and look for unexpected plugins, themes, or modified and unfamiliar PHP files. There is no official universal indicator list covering every attack, so the absence of one request pattern is not proof that the site is clean.

If you find suspicious changes, preserve a snapshot and relevant logs before cleaning, then contact the hosting provider or an incident-response specialist. After containing the incident, rotate WordPress, hosting, SFTP, and database credentials and replace the WordPress secret keys. Updating to 7.0.2, 6.9.5, or 6.8.6 closes these paths going forward, but it cannot remove a backdoor that an attacker already installed.