The Super Forms – Drag & Drop Form Builder plugin for WordPress is vulnerable to Arbitrary File Upload in…

CVE-2026-14894 is an unauthenticated arbitrary file upload in the Super Forms – Drag & Drop Form Builder WordPress plugin, versions ≤ 6.3.313. The super_submit_form nopriv AJAX handler accepts file uploads without checking authentication, file type, extension, or MIME magic bytes. Worse, the nonce that gates the upload is freely obtainable by any visitor via a second nopriv AJAX action (super_create_nonce). The result: two unauthenticated HTTP requests — one to mint a nonce, one to drop a PHP webshell into /wp-content/uploads/superforms/ — give an attacker full remote code execution on the underlying server. The fix landed in 6.3.314 on July 8, 2026.

The vendor's CRITICAL / 9.8 rating is accurate and, if anything, generous to defenders by not being a flat 10.0 (Patchstack independently scored it 10.0). There is zero friction: no authentication, no user interaction, no exotic configuration, a trivially automatable two-step chain, a public GitHub PoC, and confirmed mass exploitation with 250,000+ blocked attempts logged by Wordfence since July 14. Every unpatched instance reachable from the internet is assumed compromised until proven otherwise.

Why this verdict

• Zero authentication friction: The entire chain — nonce minting through shell upload — requires no credentials, no cookies, no user interaction. Every internet-facing instance of Super Forms ≤ 6.3.313 is in the blast radius with no narrowing conditions.
• Active mass exploitation: 250,000+ blocked attempts logged by Wordfence since July 14, 2026, with named IOC IPs and a known payload (Mushr00w_upl.php). This is not theoretical — campaigns are running *right now*.
• Public weaponized PoC: The shinthink GitHub repository provides a turnkey exploit. Nuclei templates exist. The barrier to entry for any script kiddie is near zero.
• Role multiplier: WordPress is deployed across the full role spectrum. (a) *Low-value:* dev/staging blogs — exploit succeeds, blast radius limited to site. (b) *Typical:* corporate marketing sites, customer portals — exploit succeeds, risk of data exfiltration and brand damage. (c) *High-value:* WordPress instances serving as e-commerce (WooCommerce with payment data), customer-facing portals with PII, or sites on shared hosting where www-data compromise pivots to neighboring tenants. On self-managed servers, a webshell under the web user can reach wp-config.php DB credentials, SSH keys, and flat internal networks. While WordPress itself is not a canonical high-value-role component (it is not a DC, hypervisor, or IdP), the *unauthenticated RCE with active exploitation* independently sustains the CRITICAL floor without needing the role multiplier.
• No compensating defaults: WordPress does not block PHP execution in uploads/ by default. The nonce mechanism that was supposed to gate the upload is trivially bypassable via the nopriv super_create_nonce endpoint. There is no built-in defense that stops this chain.

Why not higher?

A 9.8 is already near-ceiling. The only gap to 10.0 is Scope (S:U) — exploitation compromises the vulnerable component's server but does not inherently cross a security boundary to affect other components in a formally scoped sense. Patchstack did score it 10.0, which is defensible, but NIST's S:U is technically correct for a single-server compromise.

Why not lower?

There is no friction to discount. Every prerequisite in the chain is satisfied by default on any reachable WordPress install running the plugin. Authentication: none required. User interaction: none. Configuration dependency: none — the vulnerable AJAX endpoints are registered on plugin activation with no admin toggle. Exposure: the plugin's entire purpose is to serve public-facing forms, so the endpoints are internet-accessible by design. Active exploitation confirms that real-world conditions match the theoretical maximum severity. Downgrading would require evidence that the attack chain fails in a meaningful fraction of deployments, and no such evidence exists.

1. Block AJAX actions at the WAF layer — Add a WAF rule (ModSecurity, Cloudflare, Sucuri, or Wordfence firewall) to block requests to admin-ajax.php with action=super_submit_form or action=super_create_nonce from unauthenticated sessions. Deploy within the noisgate CRITICAL mitigation SLA of ≤ 3 days. Wordfence released a free firewall rule on July 14, 2026.
2. Disable PHP execution in uploads directory — Add an .htaccess rule (php_flag engine off) or Nginx directive (location ~* /uploads/.*\.php$ { deny all; }) to the wp-content/uploads/ directory. This breaks the chain at Step 3 even if a file is uploaded. Deploy immediately as defense-in-depth.
3. Deactivate the Super Forms plugin if not business-critical — If the form functionality can be temporarily replaced or taken offline, deactivating the plugin removes the vulnerable AJAX handlers entirely. This is the most reliable mitigation short of patching.
4. Scan for existing compromise — Check /wp-content/uploads/superforms/ for any .php files — there should be none. Search web server access logs for action=super_submit_form from external IPs. Look for the Mushr00w_upl.php filename. If found, treat the host as compromised: rotate all credentials including DB passwords in wp-config.php, review for persistence in theme/plugin files, and rebuild if possible.
5. Apply the patch (6.3.314) — Update Super Forms to version 6.3.314 or later. This is the definitive remediation. On managed WordPress hosts, check if auto-updates applied it. On self-managed hosts, update via WP CLI: wp plugin update super-forms. Must be completed within the noisgate CRITICAL remediation SLA of ≤ 90 days, but given active exploitation, treat this as immediate.

Run this on each WordPress host (or via SSH across your fleet). Requires read access to the WordPress plugin directory. Example: bash check_cve_2026_14894.sh /var/www/html where the argument is the WordPress root. No elevated privileges needed beyond file read access.

#!/usr/bin/env bash
# CVE-2026-14894 Checker — Super Forms Arbitrary File Upload
# Usage: bash check_cve_2026_14894.sh /path/to/wordpress

set -euo pipefail

WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/super-forms"
PLUGIN_FILE="$PLUGIN_DIR/super-forms.php"
UPLOAD_DIR="$WP_ROOT/wp-content/uploads/superforms"
FIXED_VERSION="6.3.314"

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN — Super Forms plugin not found at $PLUGIN_DIR"
  exit 2
fi

if [ ! -f "$PLUGIN_FILE" ]; then
  echo "UNKNOWN — Cannot read $PLUGIN_FILE"
  exit 2
fi

# Extract version from plugin header
VERSION=$(grep -i '^[[:space:]]*\*[[:space:]]*Version:' "$PLUGIN_FILE" | head -1 | sed 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not parse version from $PLUGIN_FILE"
  exit 2
fi

echo "Detected Super Forms version: $VERSION"
echo "Fixed version: $FIXED_VERSION"

# Version comparison
if [ "$(printf '%s\n' "$FIXED_VERSION" "$VERSION" | sort -V | head -1)" = "$FIXED_VERSION" ]; then
  echo "PATCHED — Super Forms $VERSION >= $FIXED_VERSION"
  STATUS=0
else
  echo "VULNERABLE — Super Forms $VERSION < $FIXED_VERSION (CVE-2026-14894)"
  STATUS=1
fi

# Check for IOCs
if [ -d "$UPLOAD_DIR" ]; then
  PHP_FILES=$(find "$UPLOAD_DIR" -name '*.php' 2>/dev/null | head -20)
  if [ -n "$PHP_FILES" ]; then
    echo "WARNING — PHP files found in uploads/superforms/ (possible compromise):"
    echo "$PHP_FILES"
    STATUS=1
  fi
fi

exit $STATUS

Sources

1. NVD – CVE-2026-14894 Detail
2. Patchstack – Super Forms Unauthenticated Arbitrary File Upload
3. GitHub PoC – shinthink/CVE-2026-14894
4. GBHackers – Critical Super Forms Flaw Actively Exploited
5. ProjectDiscovery – CVE-2026-14894 Nuclei Template
6. SecurityWeek – 300,000 WordPress Sites Exposed
7. Malware News – Attackers Actively Exploiting Super Forms
8. IONIX Threat Center – CVE-2026-14894