The User Submitted Posts WordPress plugin before 20260608 does not escape a submitted value before…

The User Submitted Posts WordPress plugin (versions before 20260608) fails to escape a user-controlled value before rendering it inside an admin-configured display context. An unauthenticated site visitor submits a post through the plugin's front-end form, embeds JavaScript into the vulnerable field, and the payload later executes when a WordPress administrator or editor views the admin-configured display area (either the wp-admin submission review screen or a shortcode-rendered page). Successful exploitation means arbitrary JavaScript running under the victim's browser origin — which for an admin means the ability to create new admin users, plant a webshell via the theme/plugin editor, or exfiltrate wp_users via nonce-authenticated AJAX.

No vendor CVSS is published for this record, so this is a first assessment, not a rescore. Judged on its merits: it's a real stored XSS in a plugin used on ~20,000+ WordPress sites per the wordpress.org install counter — meaningful footprint but not internet-scale. The attack requires no authentication to plant, which is the aggravating factor; but detonation requires an admin to actually load the poisoned view, and the blast radius stops at the one WordPress site. Vendor severity would land in the MEDIUM band under CVSS 3.1 (network vector, low complexity, no privs to plant, user interaction required, scope changed, low integrity impact on the WP tenant).

Why this verdict

• Unauth plant, auth detonation — the payload can be inserted by anonymous submitters, which is the aggravating factor; but the payload only fires when an admin/editor views the vulnerable display, which caps velocity.
• Role multiplier: low-value role (typical CMS deployment) — a public WordPress site running a submission plugin. Chain succeeds, but blast radius is one tenant's content DB + potential webshell on that one site. No lateral movement into corporate identity, no fleet impact.
• Role multiplier: high-value role does not exist for this component — User Submitted Posts is not a hypervisor, IdP, CA, backup admin, or kernel-mode agent. There is no realistic deployment where the component sits on a Tier-0 asset. Role-floor logic does not push the verdict above MEDIUM.
• Installed base ~20k sites per wordpress.org — meaningful but small; below the threshold where opportunistic mass-exploitation frameworks (WPScan modules, Wordfence attack telemetry cohorts) typically bother writing signatures the same week.
• No KEV, no active exploitation, no public PoC as of assessment — nothing pulling the score upward from the base MEDIUM.

Why not higher?

Not HIGH because the chain requires a privileged victim to load the poisoned view (UI:R), the blast radius is scoped to a single WordPress tenant, and the affected component has no plausible high-value-role deployment (no hypervisor, no IdP, no CA, no backup, no kernel agent). No KEV and no in-the-wild campaign to justify an upward pressure.

Why not lower?

Not LOW because the payload is planted unauthenticated and admin-context XSS on WordPress converts trivially to full site takeover via the plugin/theme editor or new-admin-user creation. On sites with active moderation workflows the admin will view the poisoned entry — this is not a theoretical XSS that never fires.

1. Update User Submitted Posts to 20260608 or later on every WP site — This is the primary fix. Under the noisgate remediation SLA for MEDIUM, deploy within the 365-day window — but if you have >5 WP sites running this plugin, batch it into your next monthly WP maintenance window; no reason to wait a year.
2. Set define('DISALLOW_FILE_EDIT', true); in wp-config.php on every WordPress site — This kills the plugin/theme editor path, meaning admin-context XSS can still create users but cannot drop a webshell via the file editor. Zero-cost hardening — should already be in your WP baseline. No mitigation SLA for MEDIUM, but do this the same day you touch the box.
3. Enable a WAF ruleset that inspects the plugin's submission POST for XSS payloads — Wordfence Premium, Sucuri, Cloudflare WAF managed rules, or Patchstack all ship generic XSS payload signatures that catch the raw <script> / onerror= planting attempts. Deploy on your top-N public WP sites now — plugin patch will follow.
4. Turn on CAPTCHA / hCaptcha in the plugin's submission form settings — Blocks automated planting scripts. The plugin has a built-in setting for this; toggle it via wp-admin → USP settings.
5. Add a Content-Security-Policy header restricting script-src to self + known CDNs — Blocks the external <script src=...> variant of the payload. Won't stop inline JS, but breaks the common document.write(<script src=attacker>) weaponization.

Run on the WordPress host (or via SSH from an ops jumpbox) as any user with read access to the wp-content directory. Invocation: ./check_usp.sh /var/www/html where the argument is the WordPress document root. No root required unless the wp-content directory is locked down.

#!/usr/bin/env bash
# noisgate CVE-2026-11570 detector — User Submitted Posts < 20260608
# Usage: ./check_usp.sh /path/to/wordpress
set -u
WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/user-submitted-posts"
FIXED="20260608"

if [[ ! -d "$PLUGIN_DIR" ]]; then
  echo "UNKNOWN: plugin directory not present at $PLUGIN_DIR"
  exit 2
fi

# Version lives in the plugin main file header: Version: YYYYMMDD
HEADER_FILE="$PLUGIN_DIR/user-submitted-posts.php"
if [[ ! -f "$HEADER_FILE" ]]; then
  echo "UNKNOWN: plugin header file missing"
  exit 2
fi

VER=$(grep -iE '^[[:space:]]*\*?[[:space:]]*Version:' "$HEADER_FILE" \
  | head -1 | sed -E 's/.*Version:[[:space:]]*//' | tr -d '[:space:]')

if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not parse Version from $HEADER_FILE"
  exit 2
fi

# Compare as integers (versioning is YYYYMMDD)
if [[ "$VER" =~ ^[0-9]{8}$ ]] && (( 10#$VER < 10#$FIXED )); then
  echo "VULNERABLE: User Submitted Posts $VER (< $FIXED)"
  exit 1
elif [[ "$VER" =~ ^[0-9]{8}$ ]]; then
  echo "PATCHED: User Submitted Posts $VER (>= $FIXED)"
  exit 0
else
  echo "UNKNOWN: unexpected version format: $VER"
  exit 2
fi

Sources

1. WordPress.org plugin page — User Submitted Posts
2. WPScan — prior USP Admin+ Stored XSS
3. Patchstack — USP 20230901 XSS
4. Patchstack — earlier USP 20151113 XSS
5. Rapid7 vuln DB — related USP CVE
6. Wordfence Intelligence weekly WP vuln report
7. Fastly — active exploitation of unauth stored XSS in WP plugins
8. Infosecurity Magazine — USP plugin vulnerability coverage