HIPAA Forms EUVD-2026-108010

Exploitation requires the attacker to already hold the plugin's own custom user role (PR:H) on a site running HIPAA Forms before 3.3.2; the trigger is the specific request that rebuilds that custom role, which the plugin processes without performing a capability check. The limiting factors are significant: the attacker must be authenticated AND must already possess that particular custom role (not merely any low-privilege account), so this is primarily an insider / role-holder escalation path rather than remote-unauthenticated compromise. No user interaction from a victim is needed. The complete fix per the vendor is updating to 3.3.2.

This is a genuine but conditional privilege-escalation issue (CWE-269) rather than a mass-exploitation emergency. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, 7.2) indicates network-reachable, low-complexity exploitation with no user interaction, but PR:H confirms the attacker must already be authenticated and must already hold the plugin's custom user role - this is the dominant limiting factor. The vuln.today decision label is 'this_week' (not act_now or emergency), consistent with a real-but-prioritizable issue. It is NOT in CISA KEV, so there is no confirmed active exploitation; the vendor's WPScan entry is a PoC/exploit reference that is not verified as working exploit code. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be weighed here. The signals are internally consistent: high technical impact (full admin capabilities → effective site takeover) but gated behind an elevated pre-existing role, which narrows the realistic attacker population to insiders or anyone who can already obtain that custom role. The CPE lists vendor as 'unknown', so the exact vendor identity is unconfirmed from the provided data.

A user who has already been assigned the plugin's custom HIPAA Forms role sends the request that rebuilds that role; because no capability check is enforced, they add administrator-level capabilities to their own role and thereby gain full admin control of the WordPress site. A public PoC reference exists via WPScan, though it is not verified as working exploit code. Exploitation requires that pre-existing role, so it is not an anonymous internet attack.