Flying Scripts EUVD-2026-102612

No authentication required - an unauthenticated attacker can exploit this by posting a comment, but exploitation requires that the site both runs the Flying Scripts plugin (≤1.2.4) with its JavaScript-delay output-buffer rewriting active AND accepts comments (or another input path reaching the vulnerable 'comment' parameter). The payload must be crafted to use only kses-allowed constructs (<abbr title> attribute plus a double-quote-bearing <code> body) and relies on the plugin's predictable, unsalted ___noise___ placeholder key substitution to break out of the attribute post-save; the resulting script executes only when a user subsequently views the injected page. Limiting factors: the plugin must be installed and actively rewriting output, comment (or equivalent) input must be enabled, and the attacker must construct the specific rewriter-abusing payload rather than a generic <script> tag.

This is a legitimate but moderate priority. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N = 7.2 High) is internally consistent with the description: a network-reachable, unauthenticated stored XSS whose payload survives in a page and fires in victims' browsers (scope change, low confidentiality/integrity impact, no availability impact). The standout signal is PR:N - exploitation requires no authentication, which is unusual and elevates concern for a Stored XSS. However, the real-world risk is tempered: no EPSS score was provided, the CVE is NOT in CISA KEV, and no public POC is indicated, so there is no public exploit identified at time of analysis. The impact is limited to script execution in the browser context (session/credential theft, admin-action CSRF-style abuse, content defacement) rather than direct server compromise, consistent with C:L/I:L/A:N. Note one nuance to verify: the exploitation technique is genuinely non-trivial (it depends on the plugin's output-buffer rewriter and predictable unsalted ___noise___ placeholder keys), which argues for higher attack complexity than the AC:L in the input vector suggests - the barrier to building a working payload is higher than a typical trivial reflected XSS even though the delivery (an unauthenticated comment) is simple. Overall: a real issue worth patching promptly on affected sites, but absent EPSS/KEV/POC evidence it reads as a patch-in-normal-cycle item rather than an emergency.

An unauthenticated attacker submits a blog comment on a WordPress site running Flying Scripts ≤1.2.4, embedding a payload built only from kses-allowed elements (an <abbr title> attribute and <code> text) that passes WordPress's save-time sanitization. When the plugin's HTML output-buffer rewriter later processes the page, it substitutes a double-quote-bearing <code> body into the <abbr title> attribute via predictable placeholder keys, breaking out of the attribute and injecting executable script that runs in the browser of any visitor who views the page. No public exploit is identified at time of analysis, so a working payload would have to be reconstructed from the technique described.