SliceWP EUVD-2026-112069

Exploitation requires that an attacker can submit and persist input through a SliceWP field and that a victim later views the page rendering that input (UI:R - the attack does not fire without a user loading the affected page). The specific feature, form, or endpoint carrying the injectable input is not described in the available sources, nor is the privilege level needed to store the payload; the supplied vector claims PR:N (unauthenticated) but this is unverified and atypical for stored XSS. Limiting factors: required victim interaction, dependence on the SliceWP plugin being installed and active, and the browser-context (not server-level) nature of the impact.

This is a moderate-severity stored cross-site scripting (CWE-79) flaw in the SliceWP WordPress plugin, scored 7.1 by the reporter with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L. The signals are mixed and lean toward a manage-this-week rather than emergency posture: the vuln.today Decision label is 'this_week', there is no CISA KEV listing (not actively exploited per available data), no EPSS probability was supplied, and no public exploit was provided - only a Patchstack advisory reference. The provided vector states PR:N (unauthenticated), but stored XSS in a WordPress affiliate-management plugin typically requires at least an authenticated low-privilege account to persist the payload, so the PR:N rating should be verified against the Patchstack advisory; I assess PR:L as more likely (see assessed vector). The scope-change (S:C) and limited C/I/A impacts reflect script execution in a victim's browser session rather than direct server compromise. Net: a real but not urgent issue - standard for a reporter-sourced WordPress plugin XSS with no confirmed exploitation and a niche install base.

An attacker stores a malicious JavaScript payload through an input field exposed by SliceWP; the exact field and whether an account is required are not described in the available sources. When an administrator or other user subsequently loads the page that renders the stored value, the script executes in their authenticated browser session, enabling session/action hijacking in the WordPress admin context. No public exploit code was provided - only a Patchstack advisory reference.