GiveWP CVE-2026-111980

Exploitation requires an authenticated WordPress account that holds a GiveWP custom fundraising role on a site running GiveWP before 4.19.0.1; the specific defect is that the plugin does not correctly determine which page a page-capability (edit/publish/read) request applies to, so the authorization decision is made against the wrong page. Limiting factors: the attacker cannot be fully unauthenticated - they must already possess the fundraising role (so sites that never grant this custom role are not exposed), and impact is scoped to page edit/publish/read rather than full site takeover. The trigger beyond the mis-scoped page-capability check is not further described in the available sources.

This is a moderate, authenticated broken-authorization issue (CWE-863) rather than a top-tier emergency. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N, base 5.5) indicates a network-reachable, low-complexity flaw that nonetheless requires an existing privileged account - consistent with the description, which limits the attacker to users already holding a custom GiveWP fundraising role. EPSS is very low (0.13%, 3rd percentile) and the vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the lack of CISA KEV listing: there is no public exploit identified at time of analysis as working code - only a WPScan reference exists. Note a signal tension worth flagging: the input vector sets PR:H, but the described precondition is a custom 'fundraising' role, which is typically a delegated, non-administrator role; in my independent read this is closer to PR:L, which would modestly raise the practical risk versus the PR:H rating - verify the actual capability set of that role against the GiveWP deployment. Overall this is a genuine privilege/authorization boundary defect (a lower-tier user editing/publishing admin-owned pages) but not a mass-exploitation priority: real risk is confined to multi-user sites that actually provision the fundraising role.

On a WordPress site running GiveWP before 4.19.0.1, an attacker who already holds a custom fundraising role issues page-capability requests (edit/publish/read) that the plugin incorrectly maps to pages it does not own. Because the plugin mis-determines which page the request applies to, the attacker reads, edits, and publishes pages belonging to other users including administrators. A WPScan reference exists, but it is not verified as working exploit code.