Forms WordPress Plugin EUVD-2026-100855

Exploitation requires the plugin's public-facing form submission feature to be in use, so that an unauthenticated attacker can submit a form value that is stored without sanitization. The payload only fires when a logged-in administrator (or privileged user) subsequently views the form submissions screen in the wp-admin dashboard - this required admin interaction (UI:R) is the primary limiting factor and means execution is deferred and not attacker-controlled in timing. Affected deployments are any site running the 'Forms' WordPress plugin at a version below 3.0.2; updating to 3.0.2 removes the condition. No authentication is required to plant the payload (PR:N), but no payload executes on an environment where admins never open the submissions view.

Signals point to a genuine but non-urgent risk rather than a widespread emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R) correctly captures unauthenticated remote injection, but its C:H/I:H/A:H impact rating (yielding 8.8) is aggressive for a stored XSS: the real impact is script execution in an administrator's browser session, which is better modeled as a scope change with limited direct confidentiality/integrity impact (see assessed vector). EPSS is low at 0.21% (10th percentile), and CISA SSVC lists Exploitation as 'none' and Automatable as 'no', both consistent with the absence of a KEV listing - this is NOT confirmed actively exploited. However, POC/exploit code is publicly available (WPScan) and SSVC rates Technical Impact as 'total', reflecting that successful exploitation can hijack a full administrator session. The key tension: a high CVSS and total technical impact versus low EPSS, no automatability, and a mandatory admin-interaction precondition (an admin must open the submissions screen). Net assessment: patch promptly as a meaningful admin-takeover vector, but it is not a mass-exploitation, drive-by threat. One data caveat: the affected product is identified only as a generic 'Forms' plugin with vendor 'unknown' in the CPE, so the precise plugin and its install base cannot be confirmed from the input - verify the exact plugin via the WPScan reference.

An unauthenticated visitor submits the plugin's form with a crafted field value containing a JavaScript payload (e.g., in a name or message field), which is stored unsanitized. When an administrator later opens the form submissions screen in wp-admin, the payload is output unescaped and executes in their authenticated session, enabling actions such as creating a rogue admin or planting a backdoor. Public exploit code for this stored XSS is available via WPScan, lowering the skill needed to reproduce it.