WordPress SQL Injection via author__not_in in WP_Query

WordPress 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2 does not properly sanitise the author__not_in parameter of WP_Query, which could allow SQL Injection when a plugin or theme passes untrusted input to the parameter.

• WordPress 6.8.x: Releases from 6.8.0 through 6.8.5 are affected. The fixed release is 6.8.6.
• WordPress 6.9.x: Releases from 6.9.0 through 6.9.4 are affected. The fixed release is 6.9.5.
• WordPress 7.0.x: Releases from 7.0.0 through 7.0.1 are affected. The fixed release is 7.0.2.
• WordPress states that releases before 6.8 are not affected.
• The vendor advisory also states that 7.1 beta2 contains a fix for the beta branch, but the supplied record does not fully bound the affected beta releases.

The affected component is WordPress handling of the author__not_in parameter in WP_Query. The flaw is insufficient sanitization when a plugin or theme supplies untrusted data to WP_Query. An attacker must reach a plugin or theme code path that accepts or derives attacker-controlled input and passes it to WP_Query; the record does not identify a single universal core endpoint. This creates a SQL injection condition. The WordPress advisory states that, on some later release branches, this issue can combine with a separate REST API batch-route confusion issue to reach Remote Code Execution; that outcome depends on the second issue and should not be attributed to this SQL injection in every deployment. The supplied record and vendor advisory do not establish the complete vulnerable code path or query-construction details.

• Reachability: The issue can be reached over the network when a request reaches a plugin or theme code path that passes untrusted input to the parameter.
• Authentication and interaction: The record indicates that no privileges and no user interaction are required.
• Complexity: The attack is assessed as high complexity because exploitation requires a suitable input flow into WP_Query.
• Status: The normalized record marks the vulnerability as known exploited and as having a public exploit. It does not provide specific campaign, victim, or IOC details.

The technical outcome is possible SQL injection through WP_Query handling, with high confidentiality impact recorded for the database data reachable through the flaw. The record does not record an integrity or availability impact for this issue. The flaw is network-reachable, requires no privileges or user interaction, and has high attack complexity because a suitable input path is needed. On branches that also contain the separate REST API batch issue, the WordPress advisory states that the two issues can be chained to reach Remote Code Execution; this is conditional and is not guaranteed for every deployment.

• Data exposure: SQL injection may allow database-backed WordPress data to be read, depending on the reachable code path and database account permissions.
• Operational risk: Exposed data may support further intrusion, but the available evidence does not confirm a particular breach or post-exploitation action.
• Potential escalation: The WordPress advisory states that this issue can combine with a separate REST API batch-route confusion issue to reach Remote Code Execution on some release branches. That is a chained scenario, not a confirmed outcome for every system affected only by this SQL injection.

1. Update WordPress core: Install the exact fixed release for the deployed branch: 6.8.6 for the 6.8.x branch, 6.9.5 for the 6.9.x branch, or 7.0.2 for the 7.0.x branch. A fix for one branch does not by itself establish the status of every other branch.
2. If a beta branch is in use, move to 7.1 beta2 or a later beta release only after verifying its status against WordPress guidance.
3. Review plugins and themes that pass untrusted data to author__not_in, and update or correct them according to their vendor guidance. Do not treat a plugin or theme change as a WordPress core fix unless it has been validated.
4. The supplied record does not provide a confirmed workaround. If an update cannot be applied immediately, use the organization’s exposure-reduction and incident-response procedures, but do not treat them as a substitute for updating core.

1. Inventory deployed WordPress core releases and compare them with the affected branches and fixed releases listed in affected_summary.
2. Search plugin and theme source for uses of author__not_in, then trace whether request data or another untrusted source reaches WP_Query.
3. Identify public endpoints or features that can invoke those code paths, especially where plugins or themes accept user-supplied parameters.
4. Review web server, application, and database logs for unusual requests or SQL injection probing against related plugin or theme functionality. Treat this as precautionary monitoring, not as a confirmed indicator.
5. If exploitation is suspected, preserve relevant logs and data for investigation; absence of suspicious log evidence does not prove that the system is safe.