Search in Place EUVD-2026-95604

Exploitation requires the attacker to trick a user of the WordPress site into interacting with a crafted link or page (CVSS UI:R) that targets the Search in Place plugin's search request handling, where attacker-supplied input is reflected into the generated web page without proper neutralization. No attacker authentication is required (PR:N), and the attack is deliverable remotely (AV:N), but the dependency on victim interaction is the key limiting factor - the payload only fires when a targeted user (ideally a logged-in administrator, to maximize impact) follows the malicious request. The site must be running Search in Place version 1.5.5 or earlier with the vulnerable search functionality reachable.

This is a reflected cross-site scripting (CWE-79) flaw in the codepeople 'Search in Place' WordPress plugin, versions up to and including 1.5.5, reported by Patchstack. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L) scores 7.1 (High), with the elevated score driven largely by the scope change (S:C), which is standard Patchstack methodology for XSS that executes in the victim's browser context. The signals point to a modest real-world priority rather than an urgent one: there is no CISA KEV listing (no confirmed active exploitation), no EPSS score was provided (exploitation probability unknown), and no public exploit code is referenced - only the Patchstack database advisory. Critically, exploitation is gated by UI:R (user interaction required): an attacker cannot exploit this autonomously but must lure a victim into clicking a crafted link or visiting a malicious page, which substantially lowers the realistic attack likelihood compared to a zero-interaction network flaw. The PR:N value confirms no authentication is needed by the attacker, but reflected XSS inherently depends on delivering a payload to a target user. Net assessment: a legitimate issue worth patching on a normal cadence, not an emergency - the 7.1 High rating overstates practical urgency given the required user interaction, the typically limited (low) impact of reflected XSS, and the absence of any exploitation or POC signal.

An attacker crafts a URL pointing to the vulnerable Search in Place search endpoint with a malicious script embedded in a reflected parameter, then delivers it to a victim via phishing email, a malicious link, or a hostile web page. When the victim (potentially an authenticated site administrator) clicks the link, the script executes in their browser in the context of the WordPress site, enabling session/cookie theft, actions on the victim's behalf, or redirection. No public exploit code is referenced, but reflected XSS payloads of this kind are trivial to construct.