Everest Forms CVE-2026-108491

Exploitation requires (1) an attacker able to inject and persist a script payload into Everest Forms data - typically via a form submission field or plugin setting - and (2) a subsequent victim, most plausibly an administrator or privileged user, rendering that stored data in their authenticated browser context, which is the UI:R requirement that triggers execution. Limiting factors: the attack is not self-firing (it depends on an operator viewing the malicious entry), impact is bounded to the browser session rather than the server, and despite the input's PR:N claim, persisting the payload may in practice require at least low-privilege authenticated access to the form/submission mechanism. The flaw affects Everest Forms versions through 3.6.1; sites on a later patched release are not exposed.

This is a Stored Cross-Site Scripting (CWE-79) flaw in the Everest Forms WordPress plugin (versions up to and including 3.6.1), carrying a CVSS 3.1 base score of 7.1 with vector AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. The network vector, low complexity, and scope change (S:C) indicate the injected script executes in a different security context (e.g. an administrator's authenticated browser session viewing stored form data), which is what elevates the score above a typical reflected XSS. However, several high-impact signals are MISSING: there is no EPSS exploitation-probability score provided, the vulnerability is NOT listed in CISA KEV, and no public proof-of-concept is referenced - so exploitation status is 'no public exploit identified at time of analysis.' A notable tension: the input vector asserts PR:N (unauthenticated) yet UI:R (requires an operator to view the stored payload), and Patchstack-class stored-XSS findings in form plugins very commonly require at least contributor/author-level access to persist the payload - VERIFY the privilege requirement with the vendor advisory, as PR:N may overstate reachability. Overall this is a moderate-priority, defense-in-depth issue rather than a mass-exploitation emergency: real-world risk hinges on an attacker being able to store the payload and an admin subsequently rendering it.

An attacker submits a form (or crafts plugin input) containing a malicious script payload that Everest Forms stores without proper neutralization. When an administrator later views the submitted entry or a page rendering that data in the WordPress dashboard, the script executes in the admin's authenticated session (scope change), potentially stealing session cookies or performing actions as the admin. No public exploit code is referenced, so exploitation would require an attacker to independently craft the stored payload.