fixnx
mediumCVE-2026-60137

WordPress Core 6.8 - 7.0.1 - Unauthenticated SQL Injection via author__not_in Parameter

WordPress Core is vulnerable to generic SQL Injection via the 'author__not_in' parameter in versions 6.8 - 7.0.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

Browse WordPress security risks
ProductWordPress
CVSS5.9
EPSS0.04026
UpdatedJuly 19, 2026

Quick answer

WordPress should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.

Who is affected

Affected versions

  • [6.8, 6.8.5)
  • [6.9, 6.9.5)
  • [7.0, 7.0.2)

Fixed versions

  • 6.8.6
  • 6.9.5
  • 7.0.2

How to fix it

WordPress is affected by CVE-2026-60137, an unauthenticated SQL injection flaw in the author__not_in parameter. A remote attacker can change a database query and may extract private WordPress data. Update the installed WordPress branch to 6.8.6, 6.9.5, 7.0.2, or a newer vendor-supported patched release. Prioritize exposed production systems and accounts that can reach the affected feature.

  1. Inventory every WordPress deployment, version, exposed endpoint, environment, and owner.
  2. Compare the installed release with the affected range recorded for this issue: [6.8, 6.8.5), [6.9, 6.9.5), [7.0, 7.0.2).
  3. Update the installed WordPress branch to 6.8.6, 6.9.5, 7.0.2, or a newer vendor-supported patched release.
  4. Until the update is complete, use a WAF to block SQL syntax in author__not_in and rate-limit abusive query traffic.
  5. Review relevant logs and look for encoded SQL operators, comments, delays, errors, and enumeration through author__not_in.
  6. Assess database disclosure and rotate database, application, API, and administrator secrets if logs show successful exploitation.
  7. Clear WordPress, object, page, CDN, and browser caches, then update the asset inventory and close any temporary controls only after validation.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm WordPress is on the patched version or mitigation stated above and record the exact deployed version.
  • Confirm the patched WordPress version is installed and a safe regression request cannot alter the intended author exclusion query.
  • Confirm the affected WordPress REST, AJAX, form, shortcode, upload, export, or admin feature is available only to the roles and requests that need it.
  • Review logs after remediation for continued exploit attempts or signs that the issue was used before the fix.
  • Rerun the relevant dependency, platform, vendor, or Fixnx security check and document the result, affected assets, change record, and cleanup evidence for CVE-2026-60137.

Related categories

WordPressSQL InjectionInformation Disclosure

Related security risks

More published guidance from the same primary category.

critical

WordPress Core 6.9 - 7.0.1 - Remote Code Execution via REST API Batch Request Route Confusion

Updated July 19, 2026

medium

Participants Database <= 2.7.8.3 - Missing Authorization to Unauthenticated Arbitrary Record Update / Sensitive Information Exposure via 'id' Parameter

Updated July 24, 2026

medium

Kirki <= 6.0.14 - Insecure Direct Object Reference to Unauthenticated Sensitive Information Disclosure via 'context' Parameter

Updated July 24, 2026

Trusted references

Wordfence advisoryWordfence, NVDSource advisoryWordfence, NVDSource advisoryWordfence, NVDSource advisoryWordfence, NVD

FAQ

What is affected by CVE-2026-60137?

WordPress versions listed as affected should be reviewed: [6.8, 6.8.5), [6.9, 6.9.5), [7.0, 7.0.2).

What should I fix first?

Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.

How do I confirm the fix worked?

Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.

How are Fixnx security risk categories chosen?

Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.