CVE-2026-17609: Critical Unauthenticated Directory Deletion in WordPress Super Forms Plugin — Detection and Remediation Guide

On the surface, a form builder plugin sounds like low-risk attack surface. In practice, anything that accepts unauthenticated input and touches the filesystem deserves your full attention — and CVE-2026-17609 is a textbook example of why. The NVD has published a critical vulnerability (CVSS 9.1, network-exploitable) in the Super Forms – Drag & Drop Form Builder plugin for WordPress, affecting all versions up to and including 6.3.316. An unauthenticated attacker can recursively delete arbitrary directories on the underlying server — including the WordPress root directory itself — via the plugin's submit_form function.

Let me be blunt about the impact: this is not a defacement or a data-leak bug. Recursive deletion of the WordPress root means total site destruction — application code, uploads, configuration (wp-config.php with database credentials), and any co-hosted content under the web root. If the PHP process has write permissions beyond the web root (common on misconfigured shared hosting and poorly hardened VPS deployments), the blast radius extends to other sites, application data, and backups stored on the same filesystem. Recovery from this class of attack is a rebuild-from-backup scenario, and if your backups live on the same box, you may not have a recovery scenario at all.

Super Forms is a commercially distributed form builder with a meaningful install base. If you run WordPress — or manage WordPress for clients — treat this as a patch-now item. The rest of this post breaks down the vulnerability mechanics, what exploitation looks like on the wire and on disk, and gives you concrete detection and remediation artifacts.

Technical Analysis

Affected Products and Versions

• Product: Super Forms – Drag & Drop Form Builder (WordPress plugin)
• Affected versions: All versions up to and including 6.3.316
• CVE: CVE-2026-17609
• CVSS v3.x: 9.1 (Critical) — Attack Vector: Network, no authentication required
• Vulnerability class: Arbitrary Directory Deletion (CWE-22 path traversal family / CWE-73 external control of file name or path)
• Vulnerable function: submit_form (the plugin's form submission handler, reachable through WordPress's admin-ajax.php or the plugin's AJAX endpoints — the standard unauthenticated attack surface for WordPress form plugins)

How the Vulnerability Works

The root cause is a compound failure — two defensive mistakes that multiply into a critical bug:

1. Insufficient validation of attacker-controlled JSON field declarations. When a form is submitted, Super Forms processes a JSON payload describing the submitted fields. The plugin trusts the attacker-supplied field declarations instead of validating them against the actual form schema stored server-side. In other words, the client can declare fields — and field properties — that the form was never configured to have. This is a classic trust-boundary violation: the server should treat the form definition in the database as the source of truth and reconcile the submission against it. Super Forms didn't, which lets an attacker smuggle a malicious field whose value is interpreted as a filesystem path destined for cleanup/deletion logic (the plugin deletes uploaded files and their parent directories under certain submission flows, such as file-upload handling or form deletion routines).

2. A non-effective ABSPATH guard. The developers did attempt a safety check — verifying that the path to be deleted sits within the WordPress root by comparing against ABSPATH. But the guard is trivially bypassed: dirname() strips the trailing slash from the target path, and the comparison logic fails to account for this. The practical result is that a path which resolves outside — or as — the WordPress root sails through the check. From a defender's standpoint, this is the more important lesson: guard clauses built on naive string comparison of paths are almost always bypassable via canonicalization tricks (dirname(), realpath() ordering, trailing separators, .. segments, symlinks). Path validation must happen on fully canonicalized paths with strict prefix enforcement.

Exploitation requirements: None beyond network reachability. The flaw is exploitable unauthenticated over HTTP(S) by submitting a crafted form payload to a site running a vulnerable Super Forms version. The attacker needs a reachable form endpoint (or the plugin's generic submission handler) — no credentials, no session, no user interaction. Note the truncated but critical caveat in the disclosure: exploitation requires that an admin has created a form using the plugin (i.e., the plugin must be active with at least one configured form). That narrows the exposed population slightly, but for a form builder plugin, "at least one form exists" describes virtually every production install.

Exploitation Status

As of this writing, CVE-2026-17609 has been published to the NVD with a CVSS base score of 9.1. WordPress plugin vulnerabilities with unauthenticated, network-reachable exploitation paths are historically weaponized within days of public disclosure — the WordPress ecosystem is one of the most aggressively scanned and mass-exploited surfaces on the internet. Arbitrary file/directory deletion primitives are also attractive to destructive actors and are frequently chained into extortion scenarios ("pay or we don't stop wiping"). Defenders should assume active scanning and PoC availability and operate accordingly: treat every vulnerable, internet-facing Super Forms install as an incident waiting to be confirmed.

Check CISA's Known Exploited Vulnerabilities catalog and the plugin's WordPress.org / vendor changelog for current exploitation status — if it lands on KEV, federal remediation deadlines apply and your patching clock shortens considerably.

Detection & Response

Detection for this vulnerability centers on three observable behaviors: (1) crafted form submissions carrying anomalous JSON field declarations, (2) the web/PHP process deleting files outside expected upload paths, and (3) the aftermath — mass file deletion under the web root. None of these are subtle if you're collecting the right telemetry.

Sigma Rules

The first rule targets the web request pattern: POSTs to WordPress AJAX endpoints carrying Super Forms submission parameters combined with path-traversal or absolute-path tokens in the request body — the shape of a crafted submit_form payload. The second targets host-level behavior: the web server or PHP-FPM worker spawning deletion utilities, which should essentially never happen in normal WordPress operation.

---
title: WordPress Super Forms submit_form Exploitation Attempt - CVE-2026-17609
id: 3f9c1a7e-2b84-4d61-9c05-7e8f2a1b3d44
status: experimental
description: Detects HTTP requests to WordPress AJAX endpoints containing Super Forms submission parameters alongside path traversal sequences or absolute filesystem paths, consistent with exploitation of CVE-2026-17609 arbitrary directory deletion.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-17609
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.impact
  - attack.t1485
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-uri|contains:
      - '/wp-admin/admin-ajax.php'
      - 'admin-ajax.php'
  selection_method:
    cs-method: 'POST'
  selection_payload:
    cs-body|contains:
      - 'super_form'
      - 'submit_form'
      - 'super-forms'
  selection_traversal:
    cs-body|contains:
      - '../'
      - '..%2f'
      - '..%252f'
      - '%2e%2e'
      - '/var/www'
      - '/home/'
      - 'wp-config'
      - 'wp-content/../'
  condition: selection_endpoint and selection_method and selection_payload and selection_traversal
falsepositives:
  - Rare; legitimate form submissions should not contain traversal sequences or server absolute paths
level: high
---
title: Web Server Process Spawning File Deletion Utility
id: 8b2e4d61-5c73-4a08-bf19-2d6e9c4a7f51
status: experimental
description: Detects web server or PHP-FPM worker processes spawning recursive deletion commands. WordPress and its plugins perform file operations via PHP functions, not shell utilities - this behavior is a strong indicator of post-exploitation or destructive plugin abuse such as CVE-2026-17609 chained activity.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-17609
  - https://attack.mitre.org/techniques/T1485/
  - https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.impact
  - attack.t1485
  - 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:
      - '/rm'
      - '/sh'
      - '/bash'
      - '/find'
  selection_args:
    CommandLine|contains:
      - 'rm -r'
      - 'rm -f'
      - '-delete'
      - 'wp-content'
      - 'wp-admin'
      - 'wp-includes'
  condition: selection_parent and selection_child and selection_args
falsepositives:
  - Rare; some caching or maintenance plugins shell out, but recursive deletion of core WordPress directories is never legitimate
level: critical

A note on fidelity: the first rule requires HTTP request-body logging (ModSecurity audit logs, WAF logs, reverse proxy body capture). If you only log URI and query strings, you'll miss body-carried payloads — which is a strong argument for enabling ModSecurity or cloud WAF body logging on WordPress properties. Tune the selection_payload strings against your actual Super Forms form field names if you generate false positives from legitimate submissions.

KQL — Microsoft Sentinel / Defender

This query hunts web request logs (WAF, reverse proxy, or IIS/Apache ingestion via CommonSecurityLog/Syslog) for Super Forms submission requests carrying traversal or absolute-path tokens. The second hunts host telemetry for deletion behavior under web roots.

// Hunt 1: Inbound exploitation attempts against Super Forms submit_form (CVE-2026-17609)
let TraversalTokens = dynamic(["../", "..%2f", "..%252f", "%2e%2e", "/var/www", "wp-config", "wp-content/../"]);
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has "admin-ajax.php" or RequestURL has "super-forms"
| where RequestMethod =~ "POST"
| extend Body = tostring(AdditionalExtensions)
| where Body has "super_form" or Body has "submit_form" or RequestURL has "super_form"
| where Body has_any (TraversalTokens) or RequestURL has_any (TraversalTokens)
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, Body, DestinationHostName, DeviceAction
| order by TimeGenerated desc;

// Hunt 2: Web/PHP processes executing shell deletion on Linux hosts (via Syslog or Defender for Endpoint on Linux)
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName has_any ("php-fpm", "apache2", "httpd", "nginx")
| where FileName in~ ("rm", "sh", "bash", "find")
| where ProcessCommandLine has_any ("rm -r", "rm -f", "-delete", "wp-content", "wp-admin", "wp-includes")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName
| order by TimeGenerated desc;

Velociraptor VQL

This artifact enumerates Super Forms installs across a WordPress fleet, extracts the plugin version from the plugin header, and flags vulnerable versions — ideal for scoping exposure before the patch wave, and for confirming remediation afterward.

-- Scope WordPress Super Forms plugin versions across the fleet (CVE-2026-17609)
-- Flags any version at or below 6.3.316 as vulnerable
LET plugin_files = SELECT FullPath, read_file(filename=FullPath, length=4096) AS Header
FROM glob(globs=[
  '/var/www/*/wp-content/plugins/super-forms/super-forms.php',
  '/var/www/*/*/wp-content/plugins/super-forms/super-forms.php',
  '/home/*/public_html/wp-content/plugins/super-forms/super-forms.php',
  'C:/inetpub/wwwroot/**/wp-content/plugins/super-forms/super-forms.php'
])
SELECT FullPath,
       parse_regex(data=Header, regex='Version:\\s*([0-9.]+)').g1 AS InstalledVersion,
       if(condition=parse_regex(data=Header, regex='Version:\\s*([0-9.]+)').g1 =~ '^(6\\.[0-2]\\.|6\\.3\\.([0-2]?[0-9]?[0-9]|3[0-1][0-6]))$',
          then='VULNERABLE - CVE-2026-17609', else='Review version manually') AS Assessment
FROM plugin_files

Remediation and Verification Script

Use this on Linux-hosted WordPress to inventory Super Forms installs, verify versions, take the plugin offline if it cannot be patched immediately, and check for signs of destructive activity.

#!/bin/bash
# CVE-2026-17609 - Super Forms arbitrary directory deletion
# Inventory, verify, and mitigate across WordPress docroots

VULN_MAX="6.3.316"
DOCROOTS=(/var/www /home/*/public_html /srv/www)

version_lte() {
  # returns 0 if $1 <= $2
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

echo "=== Super Forms inventory ==="
for root in "${DOCROOTS[@]}"; do
  find $root -type f -path '*/wp-content/plugins/super-forms/super-forms.php' 2>/dev/null | while read -r f; do
    ver=$(grep -m1 -oP 'Version:\s*\K[0-9.]+' "$f")
    site=$(dirname "$(dirname "$(dirname "$(dirname "$(dirname "$f")")")")")
    if version_lte "$ver" "$VULN_MAX"; then
      echo "[VULNERABLE] $site - super-forms $ver ($f)"
    else
      echo "[PATCHED]    $site - super-forms $ver"
    fi
  done
done

echo ""
echo "=== Emergency mitigation (if patch unavailable): deactivate plugin via WP-CLI ==="
echo "  wp plugin deactivate super-forms --path=/var/www/yoursite"
echo "  # Hard-block at the web server if deactivation is not possible:"
echo "  # nginx:  location = /wp-admin/admin-ajax.php { if (\$args ~* \"super_form\") { return 403; } }"
echo "  # apache (.htaccess): RewriteCond %{QUERY_STRING} super_form [NC] / RewriteRule .* - [F]"

echo ""
echo "=== Check for destruction indicators: web-root files deleted in last 72h ==="
for root in "${DOCROOTS[@]}"; do
  find $root -maxdepth 3 -name 'wp-config.php' -mmin +4320 2>/dev/null | while read -r f; do
    site=$(dirname "$f")
    missing=0
    for d in wp-admin wp-includes wp-content; do
      [ ! -d "$site/$d" ] && { echo "[ALERT] $site missing $d - possible deletion event"; missing=1; }
    done
  done
done

echo ""
echo "=== Audit web logs for exploitation patterns (last 7 days) ==="
grep -hE 'admin-ajax\.php' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null \
  | grep -iE 'super.?form' \
  | grep -iE '(\.\./|%2e%2e|\.\.\%2f|/var/www|wp-config|/home/)' \
  | tail -n 50
echo "=== Done. Patch to Super Forms > 6.3.316 immediately. ==="

Remediation

1. Update immediately. Upgrade Super Forms to the first release after 6.3.316 (check the plugin's changelog on WordPress.org or the vendor site — feel4plugins / SUPER FORMS — for the fixed version number and confirm the changelog explicitly references the directory deletion fix). Do not assume auto-updates are enabled for commercial plugins; licensed/premium WordPress plugins frequently require manual update or valid license keys for the update channel.

2. If you cannot patch within hours, deactivate the plugin. A broken form is a business inconvenience; a deleted web root is a business outage. wp plugin deactivate super-forms removes the attack surface entirely. If forms are mission-critical, fail over to an alternative form plugin temporarily.

3. Block at the edge. Deploy WAF rules (ModSecurity, Cloudflare, or your reverse proxy) denying POST bodies to admin-ajax.php containing Super Forms action parameters combined with traversal sequences or absolute paths. This is a mitigation, not a fix — payload obfuscation can potentially evade naive edge rules.

4. Verify file-system hygiene. Confirm the PHP-FPM/Apache user owns only what it must. The web user should have read-only access to wp-admin, wp-includes, and ideally all plugin/theme code (deploy code via CI, not via the web user). Restrict write access to wp-content/uploads and cache directories only. This defense-in-depth step would have capped CVE-2026-17609's blast radius even on an unpatched site — deletion of read-only core directories would fail.

5. Move backups off-box. Any backup stored on the same filesystem as the web root is inside the deletion blast radius. Verify off-site, immutable backups exist and — critically — test a full restore now. An arbitrary directory deletion bug is a recovery-plan audit you didn't schedule.

6. Hunt before you patch. Pull the last 30 days of access logs and run the grep patterns and KQL above. Exploitation may have predated disclosure. Indicators of successful exploitation include missing files/directories under the web root, anomalous 200 responses to crafted submissions, and sudden site failures with intact infrastructure.

7. Monitor CISA KEV. Given the unauthenticated, network-exploitable, destructive nature of this flaw, KEV inclusion is plausible. If added, federal agencies face BOD 22-01 remediation deadlines, and private-sector teams should treat the KEV due date as their own SLA.

8. Audit your plugin inventory. This is the recurring WordPress lesson: every plugin is unauthenticated attack surface. Inventory plugins across all properties, remove anything unused, and establish a patch SLA for critical plugin CVEs measured in hours, not weeks. A form plugin should never have been able to delete your web root — and with proper filesystem permissions and schema validation, it wouldn't have.

Related Resources

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