Autopay WordPress Plugin EUVD-2026-54994

Exploitation requires a WordPress installation with the Autopay plugin installed, active, and running a version below 5.0.1; the checkout page must be publicly accessible, which is standard for any live WooCommerce or payment plugin deployment. No authentication or special privileges are required from the attacker to plant the payload (CVSS PR:N). Exploitation is constrained by UI:R: the attacker cannot directly trigger code execution - a legitimate user must load the checkout page after the payload is stored, introducing a timing dependency. The attack surface is strictly limited to WordPress sites using this specific payment plugin; installations without Autopay are entirely unaffected. No special server configuration or network positioning is required beyond being able to send an HTTP POST to the public site.

CVSS 8.8 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) reflects a network-reachable, unauthenticated, low-complexity attack requiring only that a victim visit the checkout page. The high C/I/A scores stem from the admin-takeover path that stored XSS enables. However, EPSS at 0.17% (7th percentile) signals very limited real-world exploitation probability despite the publicly available POC - this discrepancy is typical of stored XSS, which is impactful but requires a victim to trigger execution rather than being directly automatable. No CISA KEV listing confirms the absence of confirmed mass exploitation. The S:U scope rating in the provided vector is debatable: because an unauthenticated attacker's payload executes in an authenticated administrator's browser session, many analysts would classify this as S:C. The A:H rating is also uncertain - availability impact from XSS is indirect and secondary to any admin actions taken post-compromise, not a direct consequence of the exploit itself. The practical priority is high for any e-commerce WordPress site running this plugin, driven by the admin-targeting potential and public exploit availability, but the niche deployment footprint limits aggregate exposure.

An unauthenticated attacker identifies a WordPress site running the Autopay plugin and sends a crafted HTTP POST request to the plugin's public-facing styling option endpoint, embedding a malicious JavaScript payload (e.g., a cookie-stealing script) in the styling value. The payload is stored server-side with no validation. When a WordPress administrator subsequently visits the checkout page - a routine action for order management - the stored script executes in their browser, silently exfiltrating the admin's session cookie to an attacker-controlled server. A publicly available exploit demonstrates this injection technique.