If-So Dynamic Content CVE-2026-87973

Requires an authenticated account with editor-level (or higher) capability on the WordPress site running If-So Dynamic Content between 1.9.9 and before 1.10.2 - this is the primary gate. The attacker stores a payload in a conversion name; execution only occurs when a higher-privileged user (e.g., administrator) subsequently views the plugin's analytics page, so success depends on that victim interaction (UI:R). Exploitation is limited by the need for a pre-existing trusted editor account and by the payload only triggering on a specific plugin admin page, not on arbitrary site traffic.

This is a low-severity stored XSS (CWE-79) with no signals suggesting it is a real-world priority. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N ≈ 3.0) stacks nearly every mitigating factor: high attack complexity, high privileges, and required user interaction, with only Low confidentiality and integrity impact. No EPSS score, KEV listing, or public POC is present in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' The core requirement is possession of editor-level access to the WordPress site, which is already a trusted, authenticated role - the attacker must be an insider or have compromised such an account, and then must wait for a higher-privileged user (admin) to view the analytics page. I disagree with the vendor's PR:H and AC:H choices: WordPress editor is more naturally PR:L and the victim-must-view condition is better modeled as UI:R than AC:H (see assessed vector). Even so, the realistic impact ceiling (session-context script execution against an admin viewing one specific plugin page) keeps this a Low-priority, defense-in-depth fix rather than an urgent patch.

A malicious or compromised editor-level user creates/edits an If-So conversion and sets its name to a JavaScript payload, which is stored without sanitization. When a site administrator later opens the plugin's analytics page, the unescaped conversion name renders and the script executes in the admin's authenticated session, potentially performing admin-level actions via the admin's browser. No public exploit code is identified at time of analysis.