No External Links EUVD-2026-91254

Exploitation requires the administrator to have enabled the 'Link Encoding: Base64' option in the No External Links plugin settings - this is a non-default configuration and is the primary limiting factor. Given that setting, an unauthenticated remote attacker can inject a stored script via the Log URL handling of the /goto/{base64} redirect path (vulnerable code in LogTable.php and public/Frontend.php). Execution additionally depends on a privileged user (e.g., an administrator reviewing logs) later viewing the injected page, so impact is realized only upon victim page access. Sites running ≤5.2.0 without Base64 link encoding enabled are not affected.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, base 7.2 HIGH) describes a network-reachable, unauthenticated stored XSS with a scope change, which on paper is attractive to attackers. However, several signals temper real-world urgency. No EPSS score was provided, there is no CISA KEV listing, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. Most importantly, the description explicitly gates exploitation on a non-default configuration: the administrator must have enabled the 'Link Encoding: Base64' option. This conflicts with the PR:N/AC:L framing because, while the attacker needs no privileges, success depends entirely on a target-side setting the attacker does not control - so the 'unauthenticated, low-complexity' reading overstates practical exploitability against typical deployments. The impact is also bounded (C:L/I:L/A:N), consistent with browser-side script execution rather than server compromise. Net assessment: a legitimate, vendor-reported (Wordfence) stored XSS worth patching, but a conditional, moderate-risk issue rather than a widespread emergency - prioritize only where the Base64 link-encoding feature is actually enabled.

On a site where the admin has enabled the 'Link Encoding: Base64' option, an unauthenticated attacker crafts a malicious /goto/{base64} redirect request whose URL contains a script payload. The payload is stored unsanitized and later rendered in the plugin's Log URL output, executing in the browser of any user (typically an administrator) who views the logged page. No public exploit code is referenced at time of analysis.