Podcast Importer SecondLine EUVD-2026-85486

Exploitation requires an authenticated WordPress account at Contributor role or higher on a site running Podcast Importer SecondLine <= 1.5.6 (PR:L), plus subsequent user interaction: a higher-privileged user such as an administrator must view the attacker's stored content in the admin dashboard for the injected script to execute (UI:R). The impact is a cross-privilege stored XSS (S:C) - the payload runs in the victim admin's browser context. Limiting factors: the attacker cannot exploit anonymously, must first acquire a Contributor foothold (self-registration or granted authorship), and the payload only fires when a victim renders the content, so there is no automatic or drive-by execution against default anonymous visitors.

This is a moderate-severity issue best characterized as high-CVSS-but-limited-real-risk. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L, 6.5) reflects a network-reachable but authenticated flaw: PR:L means the attacker must already hold a Contributor account, UI:R means a victim (typically an administrator) must view the injected content, and impacts are only Low across the board. No EPSS score, no CISA KEV listing, and no public POC were provided - three signals that all point to no evidence of active or imminent exploitation. There is no SSVC decision data. The A:L component is questionable for a stored XSS (script execution in a browser rarely produces a genuine availability impact); dropping it would yield roughly 6.4 with A:N. The Scope:Changed (S:C) is defensible because the Contributor's payload executes in a higher-privileged admin's browser session, crossing a privilege boundary. Net: a legitimate finding worth patching in maintenance cycles, but not an emergency given the required authenticated foothold plus victim interaction.

An attacker who has obtained or been granted a low-privilege WordPress Contributor account uses the Podcast Importer SecondLine plugin to store a malicious script payload in a field that is not properly sanitized. When an administrator later views that content in wp-admin, the script executes in the admin's authenticated session, enabling actions such as creating rogue admin users or stealing session data. No public exploit code was identified at time of analysis, and success depends on the admin viewing the injected content (UI:R).