Church Admin EUVD-2026-96100

Requires an authenticated account with subscriber-level privileges or above on a WordPress site running Church Admin ≤5.1.2; exploitation uses the plugin's 'email' parameter, which is insufficiently sanitized and escaped. The payload is stored and only fires when another user (ideally an administrator) accesses the page rendering the injected value, so impact depends on a privileged victim viewing the content. Limiting factors: the requirement for a valid low-privilege account (sites that disable open registration are far harder to attack) and the need for a victim to load the affected page; no higher privileges or non-default configuration are required beyond having the vulnerable plugin active.

This is a moderate-severity stored XSS (CVSS 6.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N) that should be treated as a patch-when-convenient issue rather than an emergency. The network vector and low attack complexity favor exploitation, but PR:L means the attacker must already hold a valid account (subscriber-level or above), which meaningfully narrows the realistic threat to sites that allow open/low-trust registration. Confidentiality and integrity impacts are Low with no availability impact, and the scope change (S:C) reflects that injected script executes in the browsers of other users/admins - the typical privilege-escalation vector for WordPress stored XSS. No EPSS score was supplied and the CVE is not listed in CISA KEV, so there is no signal of active exploitation; there is no public exploit identified at time of analysis. Signals are internally consistent (authenticated low-privilege web attack), so no conflict needs flagging, but the absence of EPSS means widespread-exploitation probability cannot be quantified from the input. Overall: a genuine but lower-tier priority, elevated only on multi-author or open-registration church sites.

An attacker registers or obtains a subscriber-level account on a WordPress site running Church Admin ≤5.1.2 and submits a crafted payload in the 'email' parameter that is stored without proper sanitization. When an administrator or other user later views the page rendering that stored value, the injected JavaScript executes in their session, enabling actions such as session/cookie theft or admin-context requests. No public exploit code is identified at time of analysis, and exploitation requires an authenticated low-privilege account.