SureForms EUVD-2026-98351

Exploitation requires (1) an authenticated account with at least submission/low-level privileges on the target WordPress site (PR:L) and (2) a higher-privileged user - typically an administrator - subsequently viewing the stored form data, satisfying the required user interaction (UI:R). The payload is injected via a SureForms form field whose input is improperly neutralized before being rendered in a web page (admin entry/review view). Limiting factors: this is not remote-unauthenticated - an attacker must first obtain a low-privileged foothold and rely on a victim admin opening the malicious submission; impact is confined to the affected plugin (SureForms ≤ 2.12.7) on WordPress installations.

This is a moderate-severity Stored XSS (CWE-79) in the SureForms WordPress plugin, scored CVSS 6.5 by Patchstack. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C indicates network-reachable, low-complexity exploitation but requires an authenticated low-privileged account (PR:L) and victim interaction (UI:R), with a scope change (S:C) reflecting that injected script executes in another user's browser context - typically an administrator viewing stored form submissions. Impact is limited (C:L/I:L/A:L), consistent with session/content compromise rather than direct system takeover. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the PR:L + UI:R combination further constrains real-world risk to scenarios where an attacker already holds a submitter/contributor-level foothold and an admin is lured into triggering the payload. This is a legitimate patch-worthy issue but not an emergency: treat it as a medium-priority fix rather than a high-urgency one, noting all signals (CVSS, absent EPSS/KEV/POC) are mutually consistent and none conflict.

An attacker with a low-privileged account (or who can submit form entries) injects a malicious script payload into a SureForms field that is stored and later rendered in the WordPress admin dashboard. When an administrator reviews the submission, the script executes in their authenticated session, enabling session hijacking or actions performed as the admin. No public exploit code is identified at time of analysis.