WP2Social Auto Publish CVE-2026-12042

Requires an authenticated administrator-level account (PR:H) able to reach the WP2Social Auto Publish admin settings page. Critically, it ONLY applies to WordPress multisite installations OR single-site installations where the unfiltered_html capability has been explicitly disabled - on default single-site WordPress, administrators natively hold unfiltered_html and can inject markup legitimately, so the flaw is not a security boundary there. These preconditions (non-default deployment mode plus high privilege) are the primary limiting factors and are why the vector carries AC:H and PR:H; no user interaction is needed for the stored payload to fire once a user views the injected page.

This is a genuine but low-priority vulnerability. The CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N, base 4.4) already reflects heavy limiting conditions: it requires an authenticated administrator (PR:H) and a non-default deployment (AC:H), yielding only Low confidentiality and integrity impact with no availability impact. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent - a high privilege requirement plus a config precondition explains the modest score, and nothing here elevates it above routine patching priority. The key nuance defenders must grasp: because exploitation demands administrator-level access AND either a multisite install or unfiltered_html being disabled, on a standard single-site WordPress an administrator already possesses unfiltered_html and can post arbitrary HTML/JS legitimately, so the flaw only becomes a meaningful boundary violation in the constrained scenarios named. This is a high-CVSS-adjacent-but-genuinely-low-real-risk issue, not an urgent one.

In a WordPress multisite network (or a site where unfiltered_html has been revoked), a lower-trust site administrator who normally should not be able to inject raw scripts saves a malicious payload through the WP2Social Auto Publish admin settings. The stored script later executes in the browser of any user who views the affected page, enabling session/action abuse in that victim's context. No public proof-of-concept is referenced in the available data.