The LearnPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the…

LearnPress is a widely-installed WordPress LMS plugin (100k+ active installs per WordPress.org). The class_wrapper_form attribute on one of its shortcodes fails to sanitize user-supplied input before rendering it inside page output. A user with contributor-or-higher role who can insert shortcodes into posts can weaponize the attribute to inject arbitrary JavaScript that executes in the browser of anyone viewing the rendered page — most usefully a site admin previewing or moderating the post.

The vendor's MEDIUM (6.4) rating is essentially correct. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N accurately reflects the trade-offs: network-reachable, low complexity, but requires *low-privilege authentication* (PR:L) and delivers only partial C/I impact. The Scope:Changed component is legitimate because stored XSS in an admin context can pivot to plugin/user management. We hold at MEDIUM — no meaningful reason to upgrade or downgrade.

Why this verdict

• Authentication gate holds: Contributor role is required. Sites with closed registration or Subscriber-default registration are effectively immune without a separate credential compromise.
• User-interaction dependency: payload only pays off when an admin/editor loads the poisoned post in an authenticated browser. That's not zero, but it removes hands-off mass exploitation.
• Role multiplier — typical role (LMS content site): chain succeeds, blast radius = single site takeover. Not a fleet or identity component. No CRITICAL floor triggers.
• Role multiplier — high-value role (WordPress multisite network or MSP-hosted fleet): on a WP multisite with LearnPress network-activated, a compromise of the super-admin session could pivot across the network, but this is an edge configuration, not the canonical LearnPress deployment.
• No KEV, no active exploitation, no public PoC at disclosure — no external pressure to elevate.
• Vendor 6.4 baseline is fair: friction (PR:L, UI-adjacent trigger, single-site blast radius) balances the S:C pivot potential.

Why not higher?

Upgrading to HIGH would require either unauthenticated exploitation, an active exploitation campaign, or a fleet-scale blast radius. None apply: PR:L is a real barrier, the payload needs a privileged viewer, and impact is bounded to one WordPress instance.

Why not lower?

Downgrading to LOW ignores that Contributor accounts are cheap on many sites (paid-membership LMS platforms often auto-provision authoring capabilities to instructors), that stored XSS in admin context has a well-documented path to full site takeover, and that patch adoption in the WP plugin ecosystem is historically slow (long tail of unpatched sites for months).

1. Update LearnPress to the patched release — Primary remediation. Push via wp plugin update learnpress or the WP admin auto-update toggle. Per noisgate remediation SLA for MEDIUM, complete within 365 days, but on any site with open contributor registration, treat this as 30-day priority.
2. Disable open registration or force Subscriber-default role — In Settings → General, uncheck 'Anyone can register' or set 'New User Default Role' to Subscriber. This closes the primary path to obtaining Contributor privileges.
3. Deploy a WAF rule blocking the vulnerable shortcode attribute — Patchstack and Wordfence Premium ship virtual patches for this class within hours of disclosure. Enable them if licensed; write a custom ModSecurity rule blocking POSTs to /wp-admin/post.php containing class_wrapper_form= with <, on\w+=, or javascript: patterns.
4. Add DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT to wp-config.php — Blocks the XSS→RCE escalation path via theme/plugin editor even if an admin session is hijacked. Standard hardening — no operational cost if you deploy via CI/CD.
5. Force MFA on all editor+ accounts — Wordfence, miniOrange, or Duo plugins. MFA doesn't stop the XSS payload itself, but it hardens the account tier that would otherwise be Contributor-role stepping stones.

Run on the WordPress host as any user who can execute wp-cli against the install (typically the web-server user). Invoke as ./check-learnpress.sh /var/www/html, passing the WordPress document root. No elevated privileges required beyond read access to the plugin directory.

#!/usr/bin/env bash
# noisgate verifier — CVE-2026-12732 LearnPress stored XSS
# Usage: ./check-learnpress.sh <wordpress-docroot>
set -u

WP_ROOT="${1:-/var/www/html}"
PLUGIN_DIR="$WP_ROOT/wp-content/plugins/learnpress"
FIXED_VERSION="4.2.9"  # UPDATE ONCE VENDOR PUBLISHES THE PATCHED RELEASE

if [ ! -d "$PLUGIN_DIR" ]; then
  echo "UNKNOWN: LearnPress not installed at $PLUGIN_DIR"
  exit 2
fi

# Prefer wp-cli if available
if command -v wp >/dev/null 2>&1; then
  INSTALLED=$(wp --path="$WP_ROOT" --allow-root plugin get learnpress --field=version 2>/dev/null)
fi

# Fallback: parse plugin header
if [ -z "${INSTALLED:-}" ]; then
  INSTALLED=$(grep -Ei '^\s*\*\s*Version:' "$PLUGIN_DIR/learnpress.php" 2>/dev/null | head -1 | awk -F: '{gsub(/ /,"",$2); print $2}')
fi

if [ -z "${INSTALLED:-}" ]; then
  echo "UNKNOWN: could not determine LearnPress version"
  exit 2
fi

# Semantic-version compare
lower_or_equal() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -1)" = "$1" ]
}

if lower_or_equal "$INSTALLED" "$FIXED_VERSION" && [ "$INSTALLED" != "$FIXED_VERSION" ]; then
  echo "VULNERABLE: LearnPress $INSTALLED < $FIXED_VERSION"
  # Secondary check — does the vulnerable shortcode handler still contain unsanitized attribute?
  if grep -RIn --include='*.php' 'class_wrapper_form' "$PLUGIN_DIR" | grep -viE 'esc_attr|sanitize_' >/dev/null; then
    echo "CONFIRMED: unsanitized class_wrapper_form reference present"
  fi
  exit 1
else
  echo "PATCHED: LearnPress $INSTALLED"
  exit 0
fi

Sources

1. NVD — CVE-2026-12732
2. WordPress.org — LearnPress plugin
3. Patchstack Vulnerability Database
4. Wordfence Threat Intelligence
5. CWE-79: Stored Cross-Site Scripting
6. WordPress Hardening — DISALLOW_FILE_MODS
7. CISA KEV Catalog
8. FIRST EPSS