CVE-2026-60137

WordPress Core SQL Injection Exploitation (CVE-2026-60137)

Detects exploitation attempts and successful exploitation of CVE-2026-60137, a SQL injection vulnerability (CWE-89) in WordPress Core affecting unauthenticated or authenticated request handling. This vulnerability is listed in the CISA Known Exploited Vulnerabilities (KEV) catalog and is actively being exploited in the wild. Exploitation typically manifests as anomalous SQL syntax in HTTP request parameters targeting WordPress endpoints (wp-admin, wp-json REST API, xmlrpc.php, plugin/theme AJAX handlers), followed by unusual database error responses, data exfiltration patterns, or subsequent webshell/backdoor deployment. WordPress 7.0.2 remediates this issue; unpatched sites remain at critical risk per CISA BOD 26-04 prioritization guidance.

Vulnerability Intelligence

KEV — Known Exploited

What is CVE-2026-60137 WordPress Core SQL Injection Exploitation (CVE-2026-60137)?

WordPress Core SQL Injection Exploitation (CVE-2026-60137) (CVE-2026-60137) maps to the Initial Access and Execution and Credential Access tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for WordPress Core SQL Injection Exploitation (CVE-2026-60137), covering the data sources and telemetry it touches: IIS Logs, Web Application Firewall Logs, Azure Front Door Logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Execution Credential Access
Microsoft Sentinel / Defender
kusto
let SuspiciousPatterns = dynamic(["UNION SELECT","UNION ALL SELECT","' OR '1'='1","information_schema","SLEEP(","benchmark(","0x2727","CONCAT(0x","--+-","xp_cmdshell"]);
W3CIISLog
| where csUriStem has_any ("/wp-admin", "/wp-json", "/xmlrpc.php", "/wp-content/plugins", "/wp-content/themes")
| where csUriQuery has_any (SuspiciousPatterns) or csUriStem has_any (SuspiciousPatterns)
| extend DecodedQuery = url_decode(csUriQuery)
| where DecodedQuery has_any (SuspiciousPatterns)
| summarize RequestCount = count(), Methods = make_set(csMethod), SampleURIs = make_set(csUriQuery, 5) by cIP, csUriStem, sSiteName, bin(TimeGenerated, 5m)
| where RequestCount >= 3
| order by RequestCount desc

Detects SQL injection payload patterns in HTTP requests to WordPress core endpoints, consistent with CVE-2026-60137 exploitation attempts against unpatched sites (pre-7.0.2).

critical severity medium confidence

Data Sources

IIS Logs Web Application Firewall Logs Azure Front Door Logs

Required Tables

W3CIISLog

False Positives

  • Security scanners and authorized penetration testing tools generating SQLi test payloads
  • Legitimate content containing SQL-like keywords in blog posts or comments being URL-encoded
  • Overly broad WAF logging capturing benign query strings with coincidental keyword matches

Sigma rule & cross-platform mapping

The detection logic for WordPress Core SQL Injection Exploitation (CVE-2026-60137) (CVE-2026-60137) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Simulate SQLi Probe Against wp-json Endpoint

    Expected signal: Web server access log entry with URI query containing 'UNION SELECT' and 'wp_users' targeting /wp-json/wp/v2/posts.

  2. Test 2Simulate SQLi Probe Against xmlrpc.php

    Expected signal: Web access log entry showing xmlrpc.php request with "' OR '1'='1" in the query string.

  3. Test 3Simulate Time-Based Blind SQLi Probe

    Expected signal: Web access log entry for admin-ajax.php containing 'SLEEP(5)' with an observable elevated response time in the log or APM data.

  4. Test 4Simulate Successful SQLi Followed by Server Error

    Expected signal: Two sequential access log entries from the same source IP within a 5-minute window: one containing 'information_schema' and one resulting in an HTTP 500 response.


Response Playbook

Triage

  1. Identify the affected WordPress instance version via wp-admin > Updates or the readme.html file; confirm whether the site is running a version prior to 7.0.2 that is vulnerable to CVE-2026-60137.
  2. Review web server and WAF logs for the flagged source IP(s) to determine the full request timeline, targeted endpoints, and injected SQL payload content.
  3. Check the WordPress database (wp_users, wp_options) for signs of unauthorized new admin accounts, modified site URLs, or altered option values indicating successful exploitation.
  4. Correlate the suspicious requests with subsequent file system changes (new PHP files in wp-content/uploads, modified theme/plugin files) suggesting webshell deployment post-exploitation.

Containment

  1. If confirmed vulnerable and unpatched, immediately isolate the site behind a WAF rule blocking known SQLi patterns targeting the affected endpoints, or take the site offline until patched.
  2. Upgrade WordPress core to version 7.0.2 or later without delay, per CISA BOD 26-04 prioritization guidance given the KEV listing; if immediate patching is not feasible, apply virtual patching via WAF/RASP.

Evidence Collection

  1. Preserve raw web server access/error logs, WAF logs, and database query logs covering the full suspected exploitation window for forensic analysis and potential legal/regulatory reporting.
  2. Export a full database dump or targeted snapshot of wp_users, wp_options, and wp_usermeta tables prior to any remediation to preserve evidence of data tampering or exfiltration.

Escalation Criteria

  • ! Escalate to incident response leadership if evidence shows successful data exfiltration from the database (e.g., large outbound data transfers correlating with the SQLi requests) or creation of unauthorized administrator accounts.
  • ! Escalate if webshells, backdoors, or persistence mechanisms are discovered on the host, indicating the SQLi was leveraged for further compromise beyond data access.

Investigation Guide

Forensic Artifacts

  • > Web server access logs showing SQLi payloads in URI query strings targeting wp-admin, wp-json, or xmlrpc.php
  • > WordPress database audit trail (if logging enabled) showing anomalous queries or unauthorized wp_users/wp_options modifications
  • > File system timestamps on wp-content/uploads or theme/plugin directories indicating newly written or modified PHP files
  • > WAF/CDN block or challenge logs correlating with the same source IPs across the exploitation window

Tuning Guidance

Baseline known internal vulnerability scanners and authorized pentest source IP ranges and exclude them from alerting to reduce noise. Adjust the request-count threshold based on site traffic volume — high-traffic sites may require a higher threshold (5-10) to avoid false positives from crawlers submitting malformed query strings. Prioritize alerts where SQLi patterns are followed by HTTP 200 responses with abnormal response sizes or 500 errors, as these more strongly indicate query execution rather than blocked/filtered attempts.


Hunting Queries

30-day retrospective hunt for low-and-slow SQL injection probing against WordPress core endpoints that may have preceded detection, useful for scoping the true start of exploitation activity.

Hunting — KQL
kql
W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any ("/wp-admin", "/wp-json", "/xmlrpc.php")
| extend DecodedQuery = url_decode(csUriQuery)
| where DecodedQuery matches regex @"(?i)(union\s+select|information_schema|sleep\(|benchmark\()"
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Count = count() by cIP, sSiteName
| order by Count desc
Hunting — SPL
spl
index=web earliest=-30d
(uri_path="*/wp-admin*" OR uri_path="*/wp-json*" OR uri_path="*/xmlrpc.php*")
| eval decoded_query=urldecode(uri_query)
| regex decoded_query="(?i)(union\s+select|information_schema|sleep\(|benchmark\()"
| stats earliest(_time) as first_seen, latest(_time) as last_seen, count by clientip, host
| sort - count

Atomic Red Team Tests

Test 1 Simulate SQLi Probe Against wp-json Endpoint
linux

Sends a UNION SELECT based SQL injection payload to a lab WordPress REST API endpoint to validate detection of CVE-2026-60137-style probing.

Command

bash
curl -s "http://LAB-WORDPRESS-HOST/wp-json/wp/v2/posts?search=1' UNION SELECT user_login,user_pass FROM wp_users--+-" -o /dev/null -w '%{http_code}\n'

Cleanup

bash
No persistent changes; no cleanup required beyond clearing local curl history if desired.

Expected Telemetry

Web server access log entry with URI query containing 'UNION SELECT' and 'wp_users' targeting /wp-json/wp/v2/posts.

Expected Detection

KQL/SPL rules should flag the request due to UNION SELECT pattern match against the wp-json endpoint.

Test 2 Simulate SQLi Probe Against xmlrpc.php
linux

Submits a boolean-based SQL injection payload (1=1) to the legacy xmlrpc.php endpoint to emulate authentication-bypass style SQLi attempts.

Command

bash
curl -s "http://LAB-WORDPRESS-HOST/xmlrpc.php?debug=1' OR '1'='1" -o /dev/null -w '%{http_code}\n'

Cleanup

bash
No persistent changes; no cleanup required.

Expected Telemetry

Web access log entry showing xmlrpc.php request with "' OR '1'='1" in the query string.

Expected Detection

Detections matching boolean-based SQLi tokens against xmlrpc.php should trigger across KQL, SPL, and QRadar AQL queries.

Test 3 Simulate Time-Based Blind SQLi Probe
linux

Sends a SLEEP()-based time-delay SQL injection payload to a lab wp-admin AJAX handler to emulate blind SQLi reconnaissance consistent with CVE-2026-60137.

Command

bash
curl -s "http://LAB-WORDPRESS-HOST/wp-admin/admin-ajax.php?action=test&id=1'+AND+SLEEP(5)--+-" -o /dev/null -w '%{http_code} time:%{time_total}\n'

Cleanup

bash
No persistent changes; verify no unintended load impact on lab database and restart lab DB service if response times remain elevated.

Expected Telemetry

Web access log entry for admin-ajax.php containing 'SLEEP(5)' with an observable elevated response time in the log or APM data.

Expected Detection

Time-based SQLi pattern (SLEEP() token) should be flagged by KQL, SPL, Elastic EQL, and Chronicle YARA-L rules.

Test 4 Simulate Successful SQLi Followed by Server Error
linux

Chains an information_schema enumeration payload with a request expected to induce a malformed query error, to validate sequence-based detection (e.g., Elastic EQL) linking SQLi probes to resulting server errors.

Command

bash
curl -s "http://LAB-WORDPRESS-HOST/wp-admin/admin-ajax.php?action=test&id=1' AND (SELECT 1 FROM information_schema.tables LIMIT 1)--+-" -o /dev/null -w '%{http_code}\n' && curl -s "http://LAB-WORDPRESS-HOST/wp-admin/admin-ajax.php?action=test&id=1'" -o /dev/null -w '%{http_code}\n'

Cleanup

bash
No persistent changes; no cleanup required beyond confirming the lab database did not enter an error state requiring restart.

Expected Telemetry

Two sequential access log entries from the same source IP within a 5-minute window: one containing 'information_schema' and one resulting in an HTTP 500 response.

Expected Detection

Elastic EQL sequence rule should correlate the two events and generate a single sequence-matched detection.

Related Detections