WP Testimonials EUVD-2026-98299

Exploitation requires an authenticated account with the Author role or higher on the target WordPress site, and requires a second user (ideally an administrator) to subsequently view the testimonials content where the stored payload renders (UI:R). The root cause is the plugin's failure to escape testimonial content combined with it actively reversing WordPress's built-in HTML sanitization, so default configurations through version 1.4.13 are affected without special settings. Limiting factors: the Author privilege requirement excludes unauthenticated and subscriber-level attackers, and no impact occurs until a victim loads the testimonials; single-user/single-admin sites with no untrusted authors have materially reduced exposure.

This is a stored (persistent) cross-site scripting flaw (CWE-79) in the WP Testimonials plugin, reported by WPScan. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:R/S:U) scores 6.8, but two signals conflict with the description and warrant verification. First, the description states exploitation requires only the Author role 'and above' - Author is a moderate, not administrative, privilege level, so PR:H appears overstated; PR:L is the more defensible choice, which would raise effective risk by lowering the barrier to a larger pool of accounts. Second, the vendor marked Scope Unchanged (S:U) yet describes the injected JavaScript executing in the session of OTHER users including administrators - a classic cross-privilege-boundary effect that argues for S:C. The C:H/I:H/A:H impact rating is also aggressive for reflected/stored XSS and likely reflects the worst-case admin-session-takeover outcome rather than the direct technical impact of script execution. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so by precision rules this is 'no public exploit identified at time of analysis.' Net: this is a genuine but second-tier priority - it requires an authenticated contributor-class account and a victim viewing the testimonials, making it well suited to insider or compromised-author scenarios and privilege escalation to admin, but not mass unauthenticated exploitation. Prioritize patching on multi-author sites; deprioritize on single-admin installations.

An attacker who holds (or phishes/compromises) a WordPress Author-level account submits a testimonial whose content embeds JavaScript that the plugin fails to escape and actively un-sanitizes on render. When an administrator later browses the testimonials, the stored script runs in the admin's authenticated session, enabling session/cookie theft, creation of a new admin, or plugin/theme modification toward full site takeover. No public exploit code is identified in the provided data, so a working payload would need to be crafted.