WPPool Dark Mode CVE-2026-93535

Exploitation requires an authenticated account with Contributor-level privileges or higher on a WordPress site running the WPPool 'Dark Mode - Improve Accessibility' plugin version 5.3.17 or earlier, and the attacker must be able to author content using the plugin's shortcode and supply a crafted 'icon_light' attribute value. The payload only fires when another user subsequently accesses the injected page. Limiting factors: the Contributor privilege gate (sites that disallow self-registration or tightly control contributor roles are largely insulated), dependence on the vulnerable plugin being installed and active, and reliance on a victim visiting the injected page for impact to materialize.

This is a moderate-priority, authenticated stored XSS flaw rather than a critical remote-code issue. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, base 6.4) shows network reach and low complexity but requires at least Contributor-level privileges (PR:L), which materially constrains the attacker pool to users who already hold a WordPress account with content-authoring rights. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided in the input, so exploitation-probability and automatability signals cannot be weighed here. No conflicting signals were observed: the description's 'authenticated attackers, with Contributor-level access and above' aligns cleanly with the CVSS PR:L metric. The scope change (S:C) and Low confidentiality/integrity impacts reflect script execution in other users'/visitors' browser contexts rather than server compromise. Overall this is a real but bounded issue - a privileged-insider / low-trust-contributor persistence vector - not a mass-exploitable unauthenticated bug; priority should scale with how many semi-trusted Contributor accounts exist on a given site.

An attacker who holds (or phishes/registers into) a Contributor-level account on a site running this plugin inserts a malicious payload into the 'icon_light' shortcode attribute while authoring a page. Because the input is neither sanitized nor output-escaped, the script is stored and later executes in the browser of any user - including administrators - who views the injected page. No public exploit code was identified at time of analysis.