Live Composer CVE-2026-16787

The attacker must hold a contributor-level WordPress account (or higher: author, editor, administrator) on the target site - unauthenticated exploitation is not possible. The Live Composer plugin must be installed and activated. The attacker must have the ability to create or edit posts or pages that render the dslc_custom_field shortcode. For impact to materialize, at least one other user (authenticated or not) must subsequently visit the page containing the injected payload - the stored payload does not self-activate without a victim page load. Sites that disable open user registration or restrict contributor role assignment significantly limit exposure. The CVSS vector PR:L confirms that some form of authentication is required.

The NVD/Wordfence CVSS score of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) correctly captures the network-accessible, low-complexity attack path and the scope change to the victim's browser, but the UI:N metric is debatable for stored XSS - standard CVSS 3.1 guidance typically assigns UI:R to payloads that require a victim to visit the injected page, which applies here. Adjusting to UI:R would yield a base score closer to 5.4. Real-world priority is moderate: the PR:L requirement means an attacker must first obtain a contributor-level WordPress account, which is a meaningful but achievable barrier on sites with open or loosely managed user registration. No EPSS data was provided and the vulnerability is not listed in CISA KEV, indicating no confirmed active exploitation. No public proof-of-concept has been identified. The practical risk is highest for sites that allow open contributor registration or have a large editorial team with untrusted members.

An attacker with a contributor-level WordPress account on the target site creates or edits a post, embedding a dslc_custom_field shortcode with a crafted attribute containing a JavaScript payload (e.g., a session cookie exfiltration script). The payload is stored in the database and rendered unsanitized each time any authenticated or unauthenticated visitor loads the page, silently executing in their browser context. No public proof-of-concept exists, but the vulnerable code paths are publicly visible in the plugin's SVN repository, lowering the barrier to independent discovery.