Slim Jetpack EUVD-2026-116807

Exploitation requires a published page or post that renders the plugin's [contact-form] shortcode; the payload is delivered through the 'website' contact field (parameter g<PAGE_ID>-website) and is stored because nonce and authentication checks are enforced only for logged-in users, leaving the submission path open to unauthenticated visitors. Against default configurations of the Slim Jetpack contact-form module this needs no authentication. The practical limiting factor is that the stored script fires only when a user - typically an administrator reviewing form submissions, or any visitor loading the injected page - actually views the affected content, so impact depends on a victim subsequently accessing it.

This is a credible but mid-tier priority rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, 7.2) indicates remote, low-complexity, unauthenticated reachability with a scope change, which is consistent with the description: the nonce and authentication checks are only enforced for logged-in users, so unauthenticated visitors can store payloads through any page bearing the [contact-form] shortcode. Only the C:L/I:L partial impacts and S:C are what push this into the 'High' band - this is a stored XSS, not code execution. No EPSS score, no CISA KEV listing, and no verified working exploit are present in the input, so there is no public signal of active or automated exploitation; the vuln.today decision label is 'this_week', not act_now or emergency, which aligns with a patch-this-cycle posture rather than drop-everything. The two plugins.trac references point to the vulnerable source lines (sanitization/escaping path) but are source code, not a packaged exploit. Net: a real issue worth remediating promptly on affected sites, but current evidence points to opportunistic/manual risk, not widespread automated exploitation.

An unauthenticated visitor locates a WordPress page or post that renders the plugin's [contact-form] shortcode and submits the form with a malicious script in the 'website' contact field, which is stored without proper sanitization or output escaping. When a site administrator later reviews the stored submissions or any user loads the page containing the injected content, the script executes in their browser in the context of the site. No public, verified exploit code is identified at time of analysis, though the Wordfence advisory and the referenced plugin source lines document the vulnerable path.