GetSocial.io WordPress Plugin EUVD-2026-100811

Requires an authenticated WordPress account with at least subscriber-level access on a site running the Social Share Buttons & Analytics - GetSocial.io plugin version ≤4.5; the attacker injects script via the 'response' parameter, which is stored in the gs-alert-msg, gs-alert-utm, and gs-alert-cta options. Execution is NOT immediate: the stored payload only runs when a logged-in administrator visits the GetSocial settings page in wp-admin, so an admin must view that specific page for impact to occur. Practical limiting factors: the target site must permit the attacker to hold a subscriber account (e.g., open user registration or compromised low-priv credentials), and the plugin at the affected version must be installed and active.

This is a genuinely moderate (not high-priority) issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N = 6.4 MEDIUM) describes a network-reachable, low-complexity stored XSS that requires only PR:L (subscriber-level authentication) and carries a scope change (S:C) because the payload stored by a low-privileged user executes in a higher-privileged administrator's browser. No EPSS score, KEV listing, POC flag, or SSVC decision data was supplied, so exploitation probability and in-the-wild activity cannot be quantified from this input - there is no public exploit identified at time of analysis. The signals are internally consistent (network vector matches a web plugin; PR:L matches the stated subscriber requirement), so there is no conflict to flag, but the real-world risk is bounded by two facts the raw score understates: an attacker must first obtain a WordPress account on the target (subscriber registration must be open or credentials obtained), and the payload only fires when an administrator happens to visit the GetSocial settings page. Net result: a real but constrained privilege-escalation-via-XSS path, not a mass-exploitable critical. EPSS would almost certainly be low; treat as routine-patch priority unless the site allows open user registration, which raises urgency.

An attacker registers or uses an existing subscriber-level account on a WordPress site running GetSocial.io ≤4.5 and submits a crafted 'response' parameter containing a JavaScript payload, which is stored unsanitized in the gs-alert-msg/gs-alert-utm/gs-alert-cta options. When an administrator later opens the GetSocial settings page, the script executes in their authenticated session, enabling actions such as creating a rogue admin or planting a backdoor. No public exploit code was identified in the provided data; exploitation is low-complexity (AC:L) but gated by the need for a valid low-privileged account and an admin viewing the affected page.