DesignSetGo CVE-2026-111068

Requires an authenticated contributor-level (or higher) WordPress account on a site running DesignSetGo ≤2.11.0, used to store a malicious 'tagName' value inside a Section/Row/Grid block delimiter comment (the value evades kses because it contains no '<'). Crucially, the payload is inert until an administrator performs a specific out-of-band action: deactivating the plugin and running the 'Scan & Convert Blocks' block-conversion migration, which triggers the vulnerable build_group_block() and writes the stored tagName into live post_content. The attacker cannot trigger execution on their own. Limiting factors: contributor authentication is mandatory, the migration is a non-default administrative step entirely outside attacker control, and exploitation only lands if/when that migration is run - all of which sharply narrow real-world exploitability.

This is a genuinely medium/low-priority issue despite being a network-vector stored XSS. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N, base 4.4) tells a consistent, de-escalating story: exploitation needs an authenticated contributor-level account (PR:L), carries high attack complexity (AC:H), and requires user interaction (UI:R). The description clarifies why complexity and interaction are high - the attacker cannot self-trigger the payload; an administrator must run the plugin's 'Scan & Convert Blocks' migration during deactivation to promote the dormant payload into live HTML. That multi-party, non-attacker-controlled precondition is the dominant risk limiter. The vuln.today decision label is 'this_month' (not act_now/emergency). No EPSS score, no CISA KEV listing, and no confirmed public exploit are present in the input, so there is no public exploit identified at time of analysis and no quantitative exploitation-probability signal to weigh - this gap should be noted rather than assumed benign. The signals do not conflict: a low-to-moderate CVSS, a routine priority label, and the absence of exploitation evidence all point the same way. This is a real but low-urgency finding, not a high-CVSS/low-real-risk mismatch.

A contributor-level user crafts a DesignSetGo Section, Row, or Grid block and sets a malicious 'tagName' (e.g. an element name carrying an onerror handler) that lives in the block delimiter comment, where WordPress kses does not treat it as markup. The payload stays dormant until an administrator deactivates the plugin and runs the 'Scan & Convert Blocks' migration, which invokes build_group_block() and writes the attacker's value directly into live post_content, executing the script in the browser of anyone who then views the page. No public exploit is identified in the input; the only code references are the vendor fix and source.