CVE-2026-11613: Unauthenticated LFI in WordPress Divi Ajax Filter — Detection, Hunting, and Remediation Guide

NVD has published CVE-2026-11613, a CVSS 9.8 (CRITICAL) Local File Inclusion vulnerability in the Divi Ajax Filter plugin for WordPress, affecting all versions up to and including 5.1.2. The flaw is reachable over the network without authentication via the custom_loop_template parameter, allowing remote attackers to include and execute arbitrary .php files on the server.

Let me be blunt about what this means operationally: an unauthenticated LFI that resolves to PHP code execution is functionally equivalent to RCE on any site where an attacker can also land a .php file on disk — and WordPress gives attackers plenty of ways to do that (media upload abuse, theme/plugin editors, other file-upload bugs, poisoned log files combined with php:// wrapper tricks in classic LFI chains). Sites running Divi Ajax Filter with the loop_templates option set to custom-template should be treated as actively exposed targets. Expect opportunistic scanning to begin within hours of PoC circulation — that has been the pattern for every critical WordPress plugin CVE of the last several years.

This post breaks down the vulnerability from a defender's perspective, provides production-ready Sigma, KQL, and Velociraptor detections, and gives you a verification and hardening script you can run against your fleet today.

Technical Analysis

Affected Products and Versions

How the Vulnerability Works (Defender's View)

The Divi Ajax Filter plugin exposes AJAX-driven filtering of Divi Builder content. When the loop_templates option is configured to custom-template, the plugin accepts a user-supplied value in the custom_loop_template parameter and passes it into a PHP include/require-style call without sufficient path validation or allowlisting.

The attack chain from the outside:

1. Recon: Attacker identifies a WordPress site running Divi Ajax Filter (plugin paths under /wp-content/plugins/..., AJAX action fingerprints, Divi theme presence).
2. Trigger: Attacker sends a crafted HTTP request (typically to wp-admin/admin-ajax.php or a plugin-specific endpoint) containing the custom_loop_template parameter with a traversal or absolute-path payload — e.g., ../../../../tmp/shell.php or a path to an attacker-planted file in uploads/.
3. Prerequisite exploitation (file landing): Because the include is restricted to .php files, the attacker needs a .php payload on disk. Common landing vectors: another upload flaw, compromised theme file editor (if DISALLOW_FILE_EDIT is not set), or writing PHP into a location the attacker controls via a secondary bug.
4. Execution: The included PHP runs with the web server's privileges (typically www-data, apache, or the PHP-FPM pool user) — full code execution within the application context.
5. Post-exploitation: Webshell drop (wso, b374k, simple system($_GET[...]) stubs), credential harvesting from wp-config.php, lateral movement into the database, SEO spam injection, or pivot to the underlying host.

Critical Scoping Note

The vulnerability is only exploitable when loop_templates is set to custom-template. This is your first triage question: is that option enabled on any site in your estate? If not, your exposure is substantially lower — but do not assume. Check the database (wp_options or plugin-specific option tables) or the plugin settings UI, per site, before deprioritizing.

Exploitation Status

At time of writing, the vulnerability is published via NVD with no confirmed CISA KEV entry. However: unauthenticated, network-reachable LFI-to-RCE in a WordPress plugin is precisely the class of bug that mass-scanning botnets weaponize within days of disclosure. Treat exploitation as imminent. If you are reading this after a PoC has surfaced, treat it as actively exploited and go straight to the hunting section.

Detection & Response

Sigma Detection Rules

These three rules cover the attack surface: the HTTP trigger (web server logs), post-exploitation command execution (web process spawning shells), and webshell staging (PHP written into uploads). Tune rule 1 to your actual web log pipeline before deployment.

---
title: WordPress Divi Ajax Filter LFI Exploitation Attempt (CVE-2026-11613)
id: 3f8a1c92-7b4d-4e6a-9c21-5e7d8f0a1b2c
status: experimental
description: Detects HTTP requests containing the custom_loop_template parameter combined with path traversal sequences, characteristic of CVE-2026-11613 exploitation against the Divi Ajax Filter WordPress plugin.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-11613
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/03/10
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_param:
    cs-uri-query|contains:
      - 'custom_loop_template='
      - 'custom_loop_template%5B'
  selection_traversal:
    cs-uri-query|contains:
      - '../'
      - '..%2f'
      - '%2e%2e'
      - '..\\'
      - 'php://'
      - '/etc/passwd'
      - 'wp-config.php'
  condition: selection_param and selection_traversal
falsepositives:
  - Legitimate use of custom_loop_template by authenticated administrators uses template names, not traversal paths or wrapper schemes
level: critical
---
title: Web Server Process Spawning Shell or Command Interpreter
id: 6b2e9d14-3c5f-4a78-b1e2-8d4f6a0c2e91
status: experimental
description: Detects PHP-FPM, Apache, or Nginx worker processes spawning shells or common post-exploitation tools, consistent with successful LFI-to-RCE exploitation of a PHP application such as WordPress.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-11613
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/03/10
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/php-fpm'
      - '/php-fpm8.1'
      - '/php-fpm8.2'
      - '/php-fpm8.3'
      - '/apache2'
      - '/httpd'
      - '/nginx'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/python'
      - '/python3'
      - '/perl'
  condition: selection_parent and selection_child
falsepositives:
  - Some backup, cache-warming, or CLI admin plugins legitimately shell out from PHP; baseline per host and suppress known tooling
level: high
---
title: PHP File Created in WordPress Uploads Directory
id: 9c4f2a87-1e6b-4d39-a7c5-2f8e1b3d6a04
status: experimental
description: Detects creation or modification of .php files inside wp-content/uploads, a classic webshell staging location following file-inclusion or upload-abuse exploitation such as CVE-2026-11613 chains.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-11613
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/03/10
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|contains: '/wp-content/uploads/'
    TargetFilename|endswith: '.php'
falsepositives:
  - Rare; a small number of plugins ship .php index guards in uploads — maintain a hash allowlist of known-good files
level: high

KQL Hunting (Microsoft Sentinel / Defender)

WordPress estates are often monitored via Syslog/CEF ingestion of Apache/Nginx access logs into Sentinel. This query hunts for the custom_loop_template exploitation pattern across ingested web logs, and a second stage looks for the downstream process execution on the host if Defender for Endpoint is present.

// Stage 1: Hunt for CVE-2026-11613 LFI attempts in ingested web access logs
let suspicious_terms = dynamic(["../", "..%2f", "%2e%2e", "php://", "/etc/passwd", "wp-config.php"]);
union isfuzzy=true
  (CommonSecurityLog | extend Uri = coalesce(RequestURL, AdditionalExtensions)),
  (Syslog | extend Uri = tostring(SyslogMessage))
| where Uri has "custom_loop_template"
| where Uri has_any (suspicious_terms)
| extend SourceIP = coalesce(SourceIP, HostIP),
         TimeGenerated = TimeGenerated
| summarize AttemptCount = count(),
            DistinctPayloads = dcount(Uri),
            SamplePayloads = make_list(Uri, 5)
  by SourceIP, Computer, bin(TimeGenerated, 15m)
| order by AttemptCount desc;

// Stage 2: Web server process spawning suspicious children (Defender for Endpoint on the web host)
DeviceProcessEvents
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx")
| where FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python3", "perl")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
          FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Pivot guidance: any source IP returned by Stage 1 should be checked against your full log retention for file-upload requests immediately preceding the LFI attempt — remember, the attacker needs a .php file on disk. Look for POSTs to media upload endpoints, /wp-admin/async-upload.php, or third-party plugin upload handlers from the same source within the preceding hours.

Velociraptor VQL Hunt

This artifact hunts the web root for .php files written into uploads/ (webshell staging) and flags recently modified PHP anywhere in the site tree — the two highest-signal disk artifacts after an LFI-to-RCE event.

-- Hunt for suspicious PHP files in WordPress web roots (webshell staging after LFI/RCE)
LET web_roots <= SELECT FullPath FROM glob(globs=['/var/www/*/wp-content/uploads/**.php',
                                                  '/var/www/html/**/wp-content/uploads/**.php',
                                                  '/srv/www/**/wp-content/uploads/**.php'],
                                          accessor='file')

SELECT FullPath,
       Size,
       Mtime,
       Ctime,
       read_file(filename=FullPath, length=512) AS HeaderSnippet
FROM web_roots
ORDER BY Mtime DESC

Follow-up triage on any hit: HeaderSnippet containing eval(, base64_decode(, system($_, shell_exec(, or assert( is near-certain malicious. Pull the full file, hash it, and check upload-timestamp correlation against access logs to identify the delivery request.

Verification and Hardening Script (Bash)

Run this against each WordPress host to (1) confirm plugin version exposure, (2) check the custom-template prerequisite, and (3) sweep access logs for exploitation attempts.

#!/usr/bin/env bash
# CVE-2026-11613 verification & hunting script — Divi Ajax Filter LFI
# Run as root (or with sudo) on each WordPress host.

WEBROOTS="/var/www /srv/www /home/*/public_html"
PLUGIN_SLUG="divi-ajax-filter"

echo "=== [1] Locating Divi Ajax Filter installs and versions ==="
for root in $WEBROOTS; do
  find "$root" -type d -name "$PLUGIN_SLUG" 2>/dev/null | while read -r plugindir; do
    mainphp=$(find "$plugindir" -maxdepth 1 -name "*.php" | head -1)
    version=$(grep -im1 "Version:" "$mainphp" 2>/dev/null | awk '{print $NF}')
    echo "  FOUND: $plugindir  |  Version: ${version:-UNKNOWN}"
  done
done

echo ""
echo "=== [2] Checking loop_templates setting (exploitation prerequisite) ==="
for root in $WEBROOTS; do
  find "$root" -maxdepth 2 -name "wp-config.php" 2>/dev/null | while read -r cfg; do
    sitedir=$(dirname "$cfg")
    echo "  Site: $sitedir"
    if command -v wp >/dev/null 2>&1; then
      (cd "$sitedir" && wp option get divi_ajax_filter_loop_templates --allow-root 2>/dev/null) | \
        sed 's/^/    loop_templates = /'
    else
      echo "    wp-cli not available — check via DB: SELECT option_value FROM wp_options WHERE option_name LIKE '%loop_template%';"
    fi
  done
done

echo ""
echo "=== [3] Sweeping web logs for exploitation attempts ==="
grep -rEih "custom_loop_template" /var/log/apache2/ /var/log/nginx/ /var/log/httpd/ 2>/dev/null | \
  grep -Ei "\.\./|\.\.%2f|%2e%2e|php://|/etc/passwd|wp-config" | \
  tail -n 50 | sed 's/^/  SUSPECT: /'

echo ""
echo "=== [4] Sweeping uploads directories for stray PHP files ==="
for root in $WEBROOTS; do
  find "$root" -path "*/wp-content/uploads/*" -name "*.php" -mtime -30 2>/dev/null | \
    sed 's/^/  REVIEW: /'
done

echo ""
echo "Done. Any SUSPECT log lines = escalate to IR. Any REVIEW files = triage contents immediately."

Remediation

Immediate (next 24 hours):

1. Update the plugin. Upgrade Divi Ajax Filter to the latest release beyond 5.1.2 as soon as the vendor patch is available via WordPress.org or the vendor's update channel. Confirm the running version post-update (wp plugin list --allow-root).
2. Kill the prerequisite. If patching is not yet possible, disable the custom-template setting for loop_templates on every affected site — the vulnerability is not exploitable without it. Verify via the plugin settings UI or directly in the options table.
3. WAF virtual patching. Deploy a blocking rule at your WAF/reverse proxy for any request where custom_loop_template appears with a value containing .., %2e, php://, or an absolute path. This is a high-fidelity, low-false-positive rule — legitimate values are template names, not paths.
4. Hunt before you patch. Apply the detections above retroactively against 90 days of retained web logs. Patching closes the door; it does not evict an attacker who already walked through it.

Short term (this week):

5. Deny PHP execution in uploads. Add a deny rule for .php execution under wp-content/uploads/ at the web server layer (.htaccess, Nginx location block, or equivalent). This neuters the most common file-landing vector for LFI chains.
6. Lock the file editor. Ensure define('DISALLOW_FILE_EDIT', true); and ideally DISALLOW_FILE_MODS in wp-config.php on production sites.
7. File integrity monitoring. Deploy FIM (or scheduled integrity hashing via Velociraptor/osquery) over the web root so any PHP file creation outside deployment windows generates an alert.

If you find evidence of exploitation: treat as a confirmed breach. Rotate all credentials in wp-config.php (database creds, auth keys/salts — which force-invalidates all sessions), audit admin accounts for rogue users, review cron and mu-plugins for persistence, and engage IR before cleanup. Webshell removal alone is not remediation.

Reference: NVD — CVE-2026-11613. Monitor the vendor's changelog and CISA KEV for escalation of exploitation status.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub