Critical Vulnerabilities in WordPress Core: What You Need to Know and How to Respond

On July 17, 2026, the WordPress security team released three patch versions—6.8.6, 6.9.5, and 7.0.2—along with two security advisories posted to the repository wordpress-develop. One of the two vulnerabilities is classified Critique and allows, in certain configurations, remote code execution.

This article details the technical nature of these vulnerabilities, the affected versions, and the steps to secure your installations.

---

Why a core vulnerability deserves your attention

The overwhelming majority of WordPress vulnerabilities disclosed each year concern third-party extensions and themes. The core code, on the other hand, benefits from a rigorous review process, a large contributor base, and a dedicated security team. Vulnerabilities are rare.

This is precisely what makes the event notable. A vulnerability in the core potentially affects all sites running the affected versions, without any specific extension being necessary for exploitation. The attack surface is no longer dependent on the administrator's choices: it is universal.

---

The two vulnerabilities

GHSA-fpp7-x2x2-2mjf — SQL Injection Facilitated in WP_Query

Severity: moderate

Affected versions:

Branch	Vulnerable versions
6.8	6.8.0 to 6.8.5
6.9	6.9.0 → 6.9.4
7.0	7.0.0 → 7.0.1

The flaw lies in the processing of the parameter author__not_in from the class WP_Query, the central component used by WordPress to build content retrieval queries.

WP_Query accepts a large number of parameters that allow filtering of returned publications. The parameter author__not_in serves to exclude authors from a set of results, normally expecting a table of numerical identifiers. A validation defect on this parameter allows unsanitized data to end up in the final SQL query.

The qualifier «facilitated» vulnerability (facilitated) used in the advisory is important: the core does not directly expose the parameter to unauthenticated user input. Exploitation assumes that an entry point—an extension, theme, custom code, or API route—passes an attacker-controlled value to this parameter. The core makes exploitation possible; the application context makes it reachable.

This explains the moderate severity rating when considering the vulnerability in isolation. This rating changes dramatically when combined.

Disclosed by: TF1T, dtro and haongo.

GHSA-ff9f-jf42-662q — Route Confusion in REST API Leading to RCE

Severity: critical

Affected versions:

Branch	Vulnerable versions
6.9	6.9.0 → 6.9.4
7.0	7.0.0 → 7.0.1

Since WordPress 6.9, the REST API offers a mechanism for grouped queries (batch requests), which allows submitting multiple operations in a single HTTP call via the endpoint /wp-json/batch/v1. This mechanism exists for performance reasons, especially on the block editor side.

The vulnerability lies in a confusion in route resolution within this mechanism. Individual requests encapsulated in a batch are not resolved and validated with the same rigor as an equivalent direct request. An attacker can exploit this discrepancy to reach, via the batch, routes or parameters that would have been filtered in direct access.

Taken in isolation, this confusion of routes is an access control problem. Combined with the SQL injection described above, it provides the missing entry point: the attacker gets a channel to inject controlled data into WP_Query, transforming a conditional vulnerability into a full exploit chain leading to the’remote code execution.

This is the classic pattern of a composite vulnerability: two individually manageable flaws, the combination of which produces an impact of a completely different order.

Disclosed by: Adam Kues (Assetnote / Searchlight Cyber).

---

Version summary

Corrected versions

• 6.8.6
• 6.9.5
• 7.0.2
• 7.1 beta2

Summary Table

Installed version	SQL Injection	RCE via REST API	Action
Less than or equal to 6.7.x	Not applicable	Not applicable	Branch update recommended
6.8.0 – 6.8.5	Vulnerable	Not applicable	Switch to 6.8.6
6.8.6	Corrected	Not applicable	Updated
6.9.0 – 6.9.4	Vulnerable	Vulnerable	Upgrade to 6.9.5 — urgent
6.9.5	Corrected	Corrected	Updated
7.0.0 – 7.0.1	Vulnerable	Vulnerable	Upgrade to 7.0.2 — urgent
7.0.2	Corrected	Corrected	Updated

The specific case of versions 6.7 and earlier

These versions are not affected by the two opinions. This is good news for now, but it hides a structural problem.

A site running 6.7 or earlier is several cycles behind. It is exposed to vulnerabilities patched between its version and the current version—public, documented flaws for which exploits have been circulating for months. Not appearing on the affected versions list this month does not constitute a secure posture.

---

What to do concretely

1. Identify your versions

From WP-CLI, on each installation:

wp core version

On a shared or multisite server, a file system scan remains the most reliable method:

find /var/www -name version.php -path '*/wp-includes/*' 2>/dev/null | \
while read f; do
  v=$(grep -oP "\\\$wp_version = '\K[^']+" "$f")
  echo -e "$v\t${f%/wp-includes/version.php}"
done | sort -V

2. Update

Via WP-CLI, while staying in the minor branch:

wp core update --minor

Or by explicitly targeting the version:

wp core update --version=7.0.2

From the administration interface: Dashboard → Updates.

3. Check afterward

The core update doesn't guarantee anything if it failed silently — a common case when file system permissions are restrictive or a plugin managing updates interferes. Always check the effective version after the operation.

4. Search for any signs of compromise

For a site remaining vulnerable in 6.9.x or 7.0.x for an extended period, an update is not enough: it closes the door but doesn't expel who may have already entered. Priority checkpoints:

• unknown administrator accounts in Users
• recently modified PHP files in wp-content/uploads/ (directory that should never contain)
• unexpected scheduled tasksWP Cron event list)
• suspicious entries in the access logs on /wp-json/batch/v1

If your site has been hacked, LRob offers a service to WordPress repair and security.

5. Prevent this from happening again

Automatic background updates for minor core versions have been enabled by default since WordPress 3.7. If your sites were not updated, it means this mechanism has been disabled—either intentionally or by a plugin. Check the constant in wp-config.php :

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Security patches fall precisely into this category.

For faster updates, LRob hosting allows automatic updates directly from the server.

---

What this episode really reveals

The time between a patch's release and the appearance of automated exploits is now measured in hours, not weeks. Mass scanners integrate new vectors almost immediately, and a lagging site isn't targeted because someone is interested in it; it's targeted because it's discoverable.

The relevant question, therefore, is not «am I up-to-date today?», but «how much time structurally passes in my organization between the release of a patch and its application?». This is a question of process, not individual vigilance.

---

The LRob Approach

At LRob, the coverage of these two vulnerabilities concerned 1.3 % of the hosted fleet at the time of the publication of notices — a direct consequence of an automated update policy applied by default.

Our WordPress hosting offer includes:

• additional WordPress-specific protections, upstream of the application code, with active banning of attackers by the servers, which drastically reduces the attack surface regardless of the installed version; ;
• the ability to enable automatic updates for the core, extensions, and themes ;
• from Comprehensive WordPress maintenance plans, including monitoring, tested backups, and incident response.

The objective is simple: for the publication of a security notice to no longer be an event requiring urgent action for you. You entrust the monitoring and application of patches, and you can sleep soundly.

Discover our WordPress maintenance plans →

---

References

• GHSA-fpp7-x2x2-2mjf — SQL injection vulnerability in the author__not_in parameter of WP_Query
• GHSA-ff9f-jf42-662q — REST API batch-route confusion and SQL injection vulnerability leading to Remote Code Execution
• Official WordPress 7.0.2 Announcement