The Form Maker by 10Web – Mobile-Friendly Drag & Drop Contact Form Builder plugin for WordPress is…

CVE-2026-3359 is an unauthenticated SQL injection in the WordPress plugin *Form Maker by 10Web* via the inputs parameter, affecting versions up to and including 1.15.42 and fixed in 1.15.43. In plain terms, a remote attacker can send crafted web requests to a site running the vulnerable plugin and manipulate backend SQL queries to read data out of the WordPress database.

The vendor's 7.5/HIGH baseline is directionally fair because the bug is remote, unauthenticated, and reachable through a public web stack. Where reality pulls it down from the edge of critical is deployment friction: only sites running this specific plugin are exposed, not every WordPress site; the most likely outcome is database disclosure rather than direct code execution; and current threat signals are weak with no KEV listing, no verified in-the-wild exploitation, and a very low EPSS.

Why this verdict

• Baseline stays high: unauthenticated remote SQLi on an internet-facing WordPress plugin is real attacker work, not theoretical lab trivia.
• Downward pressure 1 — exposed population is narrow: the bug only matters where Form Maker by 10Web is actually installed, and WordPress.org shows about 30,000+ active installs, not mass ecosystem reach.
• Downward pressure 2 — reachable flow is narrower than CVSS assumes: the attacker still needs a publicly reachable form/request path that feeds the vulnerable inputs parameter; some deployments will not present that cleanly.
• Downward pressure 3 — modern edge controls should catch commodity attempts: a tuned WAF, managed WordPress edge service, or reverse proxy often breaks stock sqlmap traffic and obvious SQL metacharacter payloads.
• Downward pressure 4 — impact is usually data theft, not instant server takeover: this CVE is about reading from the database; any move from stolen data to admin control or broader compromise requires follow-on success.
• Downward pressure 5 — threat intel is cold: no KEV entry, no verified campaign reporting, and a very low EPSS all argue against emergency-all-hands prioritization.

Why not higher?

This is not a generic WordPress core bug with massive reach, and the current record does not show active exploitation or KEV status. More importantly, the vulnerability description supports data extraction, not direct RCE, so the blast radius is materially smaller than internet-facing code execution flaws.

Why not lower?

Unauthenticated remote SQLi on a public web application is still a serious operator problem. If you do run this plugin on an exposed site, the barrier to entry is low, the tooling is mature, and even 'just' database disclosure can create credential, privacy, and regulatory pain.

1. Block exploit strings at the edge — Deploy or tune WAF/reverse-proxy rules to inspect the inputs parameter for SQL metacharacters, stacked-query patterns, boolean/time-based probes, and sqlmap-style traffic. For a HIGH verdict, put this in place within 30 days if patching cannot be completed immediately.
2. Inventory every form-maker instance — Use WordPress management tooling, file-system search, package inventory, or ASM to find every site running the plugin and mark whether it is internet-facing. Do this within 30 days so exposed systems are not hidden in the long tail.
3. Disable or remove unused forms — If the plugin is installed but not business-critical, disable the plugin or unpublish public forms to cut the reachable attack surface. Treat this as a within-30-days containment action for exposed sites.
4. Restrict reachability where possible — For admin, staging, or partner-only WordPress sites, place the site behind VPN, allowlists, identity-aware proxy, or basic edge ACLs so unauthenticated internet traffic never reaches the vulnerable flow. For a HIGH verdict, do this within 30 days on non-public use cases.
5. Watch web logs for SQLi patterns — Alert on inputs= requests containing quotes, comments, UNION, SLEEP, BENCHMARK, encoding tricks, or bursty parameter fuzzing from the same source. Stand this up within 30 days to catch exploitation attempts while patch rollouts complete.

Run this on the target WordPress host or against a mounted web root. Invoke it as bash check_form_maker_cve_2026_3359.sh /var/www/html and give it read access to the plugin files; root is not required unless the web root is permission-restricted.

#!/usr/bin/env bash
# check_form_maker_cve_2026_3359.sh
# Detects whether WordPress Form Maker by 10Web is vulnerable to CVE-2026-3359
# Usage: bash check_form_maker_cve_2026_3359.sh /path/to/wordpress
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

TARGET="${1:-}"
PLUGIN_DIR=""
VERSION=""
PATCHED_VERSION="1.15.43"

if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN - missing WordPress path argument"
  exit 2
fi

if [[ ! -d "$TARGET" ]]; then
  echo "UNKNOWN - target path does not exist: $TARGET"
  exit 2
fi

PLUGIN_DIR="$TARGET/wp-content/plugins/form-maker"
if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN - form-maker plugin directory not found at $PLUGIN_DIR"
  exit 2
fi

get_version_from_file() {
  local file="$1"
  if [[ -f "$file" ]]; then
    awk -F': *' 'tolower($1)=="version" {print $2; exit}' "$file" | tr -d '\r'
  fi
}

# Try common sources in order.
VERSION="$(get_version_from_file "$PLUGIN_DIR/readme.txt")"
if [[ -z "$VERSION" ]]; then
  VERSION="$(get_version_from_file "$PLUGIN_DIR/form-maker.php")"
fi
if [[ -z "$VERSION" ]]; then
  VERSION="$(grep -RIm1 "^[[:space:]]*Version:[[:space:]]*" "$PLUGIN_DIR" 2>/dev/null | sed -E 's/.*Version:[[:space:]]*([^[:space:]]+).*/\1/' | head -n1)"
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN - could not determine installed plugin version"
  exit 2
fi

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

vergte() {
  # returns 0 if $1 >= $2
  [[ "$1" == "$2" ]] && return 0
  local first
  first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [[ "$first" == "$2" ]]
}

if verlte "$VERSION" "1.15.42"; then
  echo "VULNERABLE - Form Maker version $VERSION is <= 1.15.42"
  exit 1
fi

if vergte "$VERSION" "$PATCHED_VERSION"; then
  echo "PATCHED - Form Maker version $VERSION is >= $PATCHED_VERSION"
  exit 0
fi

echo "UNKNOWN - version $VERSION is in an unexpected state; verify vendor backporting or packaging"
exit 2

Sources

1. NVD CVE-2026-3359
2. WordPress.org plugin page and changelog
3. WordPress Plugin Trac changeset 3518461
4. Wordfence vulnerability record
5. WPScan plugin vulnerability listing
6. Patchstack advisory
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API