Ad Inserter EUVD-2026-90545

Requires the target site to have an ad block whose code embeds the '{search-query}' dynamic tag with automatic insertion enabled - an opt-in, non-default plugin feature; sites not using this tag are not exploitable. Given that configuration, exploitation is unauthenticated (PR:N) and remote, but needs victim interaction (UI:R): the victim must follow an attacker-controlled link/frame to any ordinary post so the malicious Referer is sent. Impact is maximized when the lured visitor is a signed-in administrator. The regex bypass itself is trivial (any Referer containing a '/google.com/'-style segment passes), so the only real limiter beyond the config precondition is the social-engineering step to make a target click.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N, base 6.1) describes an unauthenticated, network-reachable reflected XSS that requires victim interaction (UI:R) and causes a scope change (S:C) with low confidentiality and integrity impact - a classic reflected-XSS profile. No EPSS score, no CISA KEV entry, and no public proof-of-concept are present in the input, so this is 'no public exploit identified at time of analysis.' The real-world risk is moderate and conditional rather than a drop-everything priority: although unauthenticated and remotely reachable, exploitation is gated by two factors not captured in the raw score - the target site must have configured an ad block that uses the '{search-query}' dynamic tag with automatic insertion enabled (a non-default, opt-in feature), and a victim (ideally a logged-in administrator) must be lured into clicking an attacker-controlled link. The flaw itself is technically sound and well-documented by Wordfence down to the exact source lines and the regex bypass, so the vulnerability is confirmed; the limiting factor is the required configuration rather than exploit difficulty. Net: a genuine but configuration-dependent reflected XSS in an otherwise very widely-deployed plugin - elevated interest due to install base, tempered by the feature-enablement precondition and need for user interaction.

An attacker crafts a malicious page whose outbound link to an ordinary post on the target WordPress site carries a Referer such as 'https://evil.test/google.com/?q=<script>...' - the leading-slash regex bypass makes the plugin treat it as a legitimate search-engine referral. When a visitor (including a signed-in administrator) follows the link, replace_ai_tags() parses the referrer with parse_str(), extracts the 'q' value, and substitutes it unescaped into the ad block's output via preg_replace(), executing the attacker's JavaScript in the victim's session. No public proof-of-concept is identified in the provided data, but the Wordfence writeup documents the exact vulnerable code paths.