FAQ Builder AYS EUVD-2026-69858

No authentication is required to inject the payload - exploitation begins with a standard HTTP POST to the plugin's public-facing FAQ submission endpoint, available on any WordPress site with the plugin installed and active (versions 1.6.3 through 1.8.4). The required trigger condition is that a logged-in WordPress administrator must subsequently navigate to the admin panel page where submitted FAQ entries are displayed; the XSS does not execute until this admin page view occurs. No non-default configuration is needed - the plugin's default behavior accepts public submissions and renders them in the admin area without sanitization. Exploitation is bounded by: (1) running an unpatched version before 1.8.5, and (2) requiring at least passive admin interaction with the submissions queue, which is routine for any active WordPress site using this plugin.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, score 8.8) accurately captures the core attack profile - network-accessible, low complexity, no credentials required - but the S:U (unchanged scope) designation is conservative. Stored XSS executing in an admin session effectively grants the attacker control over the entire WordPress installation (plugin installation, user creation, content modification), which is better modeled as S:C and would push the score above 9.0. The sole real-world friction is UI:R: an administrator must view the poisoned admin page. However, routine admin review of incoming FAQ submissions makes this trigger highly probable rather than exceptional. A publicly available POC from WPScan significantly lowers attacker skill requirements. No CISA KEV listing exists at time of analysis, suggesting no confirmed mass exploitation, but the unauthenticated submission path combined with a public exploit creates a high-priority patching window. No EPSS data was provided, so exploitation probability cannot be numerically quantified.

An unauthenticated attacker submits a FAQ entry through the plugin's public-facing form, embedding a JavaScript payload such as a session-cookie exfiltrator or a script that silently creates a backdoor administrator account. The plugin stores the entry, and its internal decoding step reverses the partial escaping, preserving the payload. When a WordPress administrator next opens the FAQ submission management page, the script fires in their browser, granting the attacker administrative access to the WordPress site. A public proof-of-concept is available via WPScan.