EventPrime EUVD-2026-42559

Two distinct paths exist. Path 1 (unauthenticated) requires the plugin's Guest Submissions setting, allow_submission_by_anonymous_user, to be ENABLED - this is a non-default configuration that exposes the front-end event-type submission form to anonymous users; the injection targets the 'new_event_type_background_color' parameter. Path 2 (default configuration, Guest Submissions disabled) requires at minimum a valid subscriber-level authenticated WordPress account with the plugin's custom-level (event-creation) access. Payload execution is limited by requiring a victim to subsequently view a page that renders the injected event type; there is no availability impact and only Low confidentiality/integrity impact. The decisive limiting factor for real-world risk is the state of the Guest Submissions setting.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N, base 7.2) reflects the worst-case path where the plugin's Guest Submissions setting (allow_submission_by_anonymous_user) is enabled, permitting unauthenticated front-end submission - that is what justifies PR:N and the scope change (S:C) typical of stored XSS crossing into the admin/viewer context. This is a notable conflict with the description, which states that in the DEFAULT configuration (Guest Submissions disabled) at least a subscriber-level authenticated account is required; under default settings the honest privilege metric is PR:L, lowering real-world severity. No EPSS score, SSVC decision, or POC indicator was provided, and KEV status is not listed - so exploitation probability cannot be quantified from the input. Overall this is a credible but moderate-priority issue: stored XSS with only Low confidentiality/integrity impact and no availability impact, whose true exposure hinges entirely on whether Guest Submissions is enabled. Treat as elevated priority on sites with anonymous event submission enabled, routine-patch priority otherwise.

On a site where Guest Submissions is enabled, an unauthenticated attacker opens the public event-submission form and creates an event type with a JavaScript payload placed in the background-color field; when an administrator or visitor later loads a page rendering that event type, the script executes in their session. If Guest Submissions is disabled, an attacker first registers or obtains a subscriber-level account, then performs the same injection. No public exploit code has been identified, but the low complexity (AC:L) and network vector make weaponization straightforward.