CVE-2026-60137 Google Chronicle · YARA-L

Detect WordPress Core SQL Injection Exploitation (CVE-2026-60137) in Google Chronicle

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.

MITRE ATT&CK

Tactic
Initial Access Execution Credential Access

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule wordpress_core_sqli_cve_2026_60137 {
  meta:
    description = "Detects SQLi patterns targeting WordPress core endpoints (CVE-2026-60137)"
    severity = "CRITICAL"
    cve = "CVE-2026-60137"
  events:
    $e.metadata.event_type = "NETWORK_HTTP"
    $e.target.url = /(\/wp-admin|\/wp-json|\/xmlrpc\.php|\/wp-content\/plugins)/ nocase
    $e.network.http.method != ""
    $e.target.url = /(UNION(\s|%20)+SELECT|1(\s|%20)*=(\s|%20)*1|information_schema|SLEEP\(|benchmark\(|0x2727)/ nocase
  match:
    $e.principal.ip over 5m
  condition:
    $e
}
critical severity medium confidence

Chronicle YARA-L rule matching SQL injection syntax in HTTP requests to WordPress core paths, aligned with active KEV exploitation of CVE-2026-60137.

Data Sources

Network HTTP EventsWeb Proxy Logs

Required Tables

NETWORK_HTTP

False Positives & Tuning

  • Legitimate security research or authorized penetration testing traffic
  • Third-party monitoring integrations that mirror raw query strings into logs
  • Rare but valid application query parameters coincidentally matching regex tokens

Other platforms for CVE-2026-60137

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-07-22 Research depth: standard
References (4)

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

Related Techniques

[object Object][object Object][object Object]

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

Tactic Hubs

TA0001Initial AccessTA0002ExecutionTA0006Credential Access

Related Techniques

T1190Exploit Public-Facing ApplicationT1505.003Web ShellT1078Valid Accounts

Same Tactic: Initial Access

Popular Detections