Contact Form by Supsystic CVE-2025-15705

Exploitation requires an authenticated account with access to the Contact Form by Supsystic form editor (PR:H), the ability to set a form name, and a second user who subsequently views that form (UI:R) for the stored payload to execute - it is not remote-unauthenticated. The elevated-impact case is specifically limited to WordPress multisite installations, where site administrators do not hold the unfiltered_html capability; there, injecting script crosses a privilege boundary toward higher-trust users. On single-site installations, form-editor users typically already possess unfiltered_html, so no meaningful boundary is crossed. The fix is upgrading to Contact Form by Supsystic 1.8.0 or later, which the vendor has made available.

This is a low-severity, authenticated stored XSS (CVSS 3.1 base 3.5, CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:N) that is not a broad-fleet priority. The signals are internally consistent and all point the same way: PR:H confirms the attacker must already hold a privileged role (access to the form editor), UI:R confirms a second user must view the affected form for the script to fire, and C:L/I:L/A:N reflect the limited impact typical of script injection in another user's session. EPSS is 0.15% (4th percentile), indicating no meaningful mass-exploitation pressure, and the vuln.today decision label is 'monitor' - not an act-now item. The flaw is NOT in CISA KEV, so there is no public attack-chain weaponization pressure: no public exploit identified at time of analysis as working exploit code, though a public PoC/advisory reference exists at WPScan (see conditions below). The one genuinely interesting nuance, stated by the description rather than any score, is the multisite privilege-boundary crossing: because site administrators on multisite do not hold unfiltered_html, a lower-trust site admin can inject script that executes for higher-trust users (e.g. super admin), which is the main reason this merits any attention beyond routine patching. On single-site installs where the form editor is held by trusted admins who already have unfiltered_html, the practical security boundary crossed is minimal.

On a WordPress multisite install, an authenticated site administrator (who lacks the unfiltered_html capability) uses the Contact Form by Supsystic form editor to create or rename a form, embedding a malicious script in the form name. When a higher-privileged user such as a network/super admin later views that form, the stored script executes in their browser session. A public PoC reference exists at WPScan but is not verified as working exploit code, and the AC:L/UI:R profile means exploitation is simple but requires that a victim actually open the affected form.