MW WP Form CVE-2026-96567

Requires a publicly accessible, published MW WP Form form on the target WordPress site (the plugin's core use case). The attacker must first request that public form page to obtain a valid double-submit cookie, which per the report defeats the MW_WP_Form_Csrf protection, then submit a crafted 'post_id' value; no authentication is required (PR:N). The practical limiting factor is that the stored payload only fires when a user later accesses the injected page, so impact depends on victims - ideally privileged administrators - viewing that page. No non-default configuration is needed beyond having an active form, and exploitation applies to all versions through 5.1.7.

This is a genuine but moderate-priority issue rather than a drop-everything emergency. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C) describes a network-reachable, low-complexity, unauthenticated stored XSS with a scope change, which is why it rates 7.2 (High). The impact is correctly bounded to C:L/I:L/A:N, consistent with script execution in a victim's browser session rather than full server compromise. No EPSS score was provided in the input, so exploitation probability cannot be quantified. The CVE is not listed in CISA KEV and no proof-of-concept is referenced, so this is no public exploit identified at time of analysis. No SSVC decision data was supplied. The most important nuance is that although the base vector is PR:N/UI:N, stored XSS realistically depends on a victim later loading the poisoned page - the UI:N reflects the Wordfence convention that the triggering victim need take no special action beyond normal browsing, not that zero human interaction occurs. The description's claim that the MW_WP_Form_Csrf double-submit gate is trivially bypassable by any visitor is a vendor (Wordfence) assertion and strengthens the unauthenticated-attacker characterization. Overall: a real, patch-worthy vulnerability whose severity is mitigated by the limited (XSS-scoped) impact and the absence of evidence of active exploitation or public exploit code.

An unauthenticated attacker first loads the public MW WP Form page to obtain a valid double-submit CSRF cookie, then submits the form with a malicious script payload in the 'post_id' parameter, which is stored without sufficient sanitization. When any user - including a logged-in administrator - subsequently views the affected page, the injected JavaScript executes in their browser, enabling session hijacking or admin-context actions. No public exploit code is referenced, so exploitation would currently require an attacker to craft the request manually from the described mechanism.