WordPress Core Is Being Exploited Right Now: What Your Association Needs to Do This Week

On July 17, 2026, WordPress.org published version 7.0.2 to fix two vulnerabilities that chain together into unauthenticated remote code execution. Attackers can take complete control of an affected WordPress site without logging in. No credentials required. No social engineering. No phishing. Just a crafted HTTP request to a REST API endpoint that every WordPress installation exposes by default.

This is not theoretical. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on July 21. Wiz Research documented active post-exploitation, including webshell deployment, within hours of disclosure. Security researchers are calling it wp2shell, and the name is accurate: two bugs, chained, give an attacker a shell on your server.

If your association runs WordPress, this affects you. Here is what happened, whether you are actually protected, and what to do right now.

What the Vulnerabilities Are

Two separate flaws combine into a single exploit chain:

CVE-2026-60137 is a SQL injection vulnerability in WP_Query's author__not_in parameter. It exists in WordPress 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1. An attacker who can reach this parameter can inject SQL statements that read or modify anything in the WordPress database, including user credentials and administrator accounts.

CVE-2026-63030 is a REST API batch-route confusion issue introduced in WordPress 6.9. It allows an unauthenticated attacker to access internal REST API endpoints that should require authentication. This vulnerability, reported by Adam Kues at Assetnote/Searchlight Cyber, is the gateway that makes the SQL injection reachable without credentials.

Chained together, these two flaws give an unauthenticated attacker full control of any affected WordPress site. The attacker can create administrator accounts, install malicious plugins, upload webshells, read your entire database, and pivot to other systems on your network.

The Patched Versions

WordPress 7.0.2 fixes both vulnerabilities for sites running WordPress 7.0.x.

WordPress 6.9.5 fixes both vulnerabilities for sites running WordPress 6.9.x.

WordPress 6.8.6 fixes the SQL injection (CVE-2026-60137) only. Sites on 6.8.x are not affected by the REST API route confusion issue, which was introduced in 6.9.

WordPress.org took the unusual step of enabling forced auto-updates for affected sites. In theory, if your site has auto-updates enabled and can write to the filesystem, it should have received the patch automatically.

In practice, "auto-updates were forced" does not mean your site is patched.

Why Auto-Updates May Not Have Saved You

The reassurance in most coverage of this vulnerability is that forced auto-updates have already resolved the issue for most sites. That reassurance does not transfer cleanly to several common hosting configurations:

Git-based managed hosting (Pantheon, Platform.sh). On platforms like Pantheon, WordPress core is committed to the repository and the filesystem is read-only on test and live environments. WordPress cannot update itself in place. The update happens when a developer commits the new version through git, not when WordPress fires its auto-updater. If nobody on your team committed the update, you are still running the vulnerable version regardless of what WordPress.org enabled.

Sites with auto-updates disabled. Some hosting configurations, staging environments, and sites where someone added a "disable auto-updates" plugin or set AUTOMATIC_UPDATER_DISABLED to true in wp-config.php will not have received the forced update. This is more common than you might expect, especially on sites managed by agencies that prefer to test updates before applying them.

Forgotten subdomains and staging copies. Many associations have staging environments, development copies, or old subdomains running WordPress that nobody actively monitors. These installations are just as vulnerable and just as reachable from the internet as your production site.

Composer-managed or custom deployment pipelines. Organizations using Composer, Bedrock, or other dependency management systems to manage WordPress core control updates through their build process, not through WordPress's auto-updater.

Patched Does Not Mean Clean

This is the part most coverage gets wrong, and it is the part that matters most. If your site was running a vulnerable version at any point between July 17 and whenever your patch was applied, updating WordPress does not remove a backdoor.

Wiz Research documented post-exploitation activity beginning almost immediately after the vulnerabilities were disclosed. Attackers were deploying webshells, creating rogue administrator accounts, and installing malicious plugins within hours. The exploitation involved:

• Malicious plugin uploads through /wp-admin/plugin-install.php, including a fake "security plugin" containing persistent backdoor code
• User enumeration via the REST API users endpoint to identify existing administrator accounts
• Rogue administrator account creation giving attackers persistent access even after the vulnerability is patched
• Three distinct webshell variants, including a 150-kilobyte variant with file management and privilege escalation modules, deployed to /wp-content/cache/ with randomized filenames

A core update closes the front door. It does not remove the attacker who already walked through it. If your site was exposed during the vulnerability window, you need to actively look for signs of compromise, not just verify the version number.

What Your Association Should Do Right Now

Step 1: Confirm your WordPress version. Log into your WordPress dashboard and check the version number under Dashboard > Updates. You need to be on 7.0.2, 6.9.5, or 6.8.6 at minimum. If you cannot log in, check wp-includes/version.php directly. If you are on managed hosting, contact your hosting provider and confirm the version running on your live site.

Step 2: If you are not patched, update immediately. Every hour an unpatched WordPress installation is exposed to the internet is an hour an attacker has to exploit it. If you cannot update immediately, apply the interim mitigation: block requests to /wp-json/batch/v1 and ?rest_route=/batch/v1 at your web server or WAF level. This is a stopgap, not a fix.

Step 3: Check for signs of compromise. Even if you are now patched, if your site was running a vulnerable version at any point after July 17, you need to look for evidence of exploitation:

• Check your user list for any administrator accounts you do not recognize. Go to Users > All Users and filter by Administrator role. If there are accounts you did not create, your site was compromised.
• Check for unexpected files in wp-content/uploads/, wp-content/cache/, and wp-content/plugins/. Look for PHP files that should not be there, especially files with randomized names. Any .php file in your uploads directory is a red flag.
• Review your server access logs for POST requests to /wp-json/batch/v1 or ?rest_route=/batch/v1 containing SQL-like strings (SELECT, UNION, SLEEP) in the request body. HTTP 207 responses to these endpoints are a high-confidence exploitation signal.
• Check for unauthorized plugins. Go to Plugins > Installed Plugins and look for anything you do not recognize. Attackers deployed webshells disguised as security plugins.
• Review scheduled events. Use a plugin like WP Crontrol to check for cron jobs you did not create. Attackers use scheduled tasks to maintain persistence.

Step 4: Check every WordPress installation you operate. This includes staging environments, development sites, microsites, and any subdomain running WordPress. Forgotten installations are the most vulnerable because nobody is monitoring them.

Step 5: If you find evidence of compromise, do not just clean the files. A compromised WordPress site requires a thorough remediation: reset all user passwords, regenerate WordPress salts and secret keys in wp-config.php, reinstall WordPress core from a clean copy, audit every plugin and theme, and review the database for injected content. If you do not have the technical expertise to do this confidently, bring in a professional.

The Bigger Problem This Reveals

This exploit is a worst-case scenario, but the underlying problem is routine. WordPress core, plugin, and theme vulnerabilities are disclosed every week. The wp2shell chain is exceptional in its severity, but the pattern is not: a vulnerability is published, a patch is released, and organizations that do not have active technical management scramble to figure out whether they are affected.

For associations without dedicated technical staff or an ongoing web management partnership, the response to every vulnerability is the same reactive scramble. Who has the login? Who knows how to check the version? Who can apply the update? Who knows how to check for compromise after the fact? These questions should have answers before the crisis, not during it.

This is exactly the kind of situation a web partnership prevents. A dedicated web partner monitors your site continuously, applies security patches as soon as they are released, checks for indicators of compromise, and has the context and access to respond immediately when a critical vulnerability drops. Your association staff should never have to figure out what wp-includes/version.php is or how to search access logs for exploitation signatures.

Post 129 | 83 Creative | 83creative.com