CVE-2026-111980 in GiveWP Plugin
Summary
by MITRE • 10/25/2026
The GiveWP WordPress plugin before 4.19.0.1 does not correctly determine which page a page-capability request applies to, allowing users with a custom fundraising role to edit, publish and read pages owned by other users, including administrators.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in the GiveWP WordPress plugin prior to version 4.19.0.1 represents a critical failure in access control logic within the context of content management systems. This flaw specifically impacts the mechanism used to validate page capabilities for custom fundraising roles created by site administrators. In standard WordPress architecture, capability checks are designed to ensure that users can only perform actions on resources they own or have been explicitly granted permission to manage. However, due to an incorrect determination logic regarding which specific page a request targets, the plugin fails to enforce these boundaries correctly. This architectural oversight allows authenticated users with custom fundraising roles to bypass intended restrictions and interact with pages belonging to other users, including those holding the highest privilege level of administrator.
From a technical perspective, this issue is classified as an authorization failure where the application does not properly verify that the requesting user has permission for the specific resource in question. The root cause lies in how the plugin processes capability requests during page editing or publishing operations. Instead of binding the permission check to the unique identifier of the target post object, the logic likely relies on a global state or an incorrect variable reference that does not distinguish between different pages within the same request cycle. This allows a user with limited privileges to manipulate the internal variables associated with administrative content, effectively elevating their capabilities beyond what was intended by the site configuration. Such flaws are particularly dangerous in multi-author environments where distinct roles must be strictly segregated to maintain data integrity and security boundaries.
The operational impact of this vulnerability is severe, as it compromises both confidentiality and integrity within the WordPress installation. Users with custom fundraising roles can read sensitive content stored on pages owned by administrators, potentially exposing proprietary business information or private donor details if such data were ever placed in those locations. More critically, these users gain the ability to edit and publish changes to administrative pages. This means an attacker could deface official site communications, inject malicious scripts into trusted areas of the website, or alter critical configuration settings that are typically protected from lower-privileged accounts. The erosion of trust between different user roles undermines the fundamental security model of the content management system, allowing lateral movement and privilege escalation within the application layer without requiring any external exploitation techniques like SQL injection or cross-site scripting.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-269, which describes Improper Privilege Management, specifically focusing on situations where a user can perform actions beyond their authorized scope due to flawed logic in permission checks. It also maps directly to the MITRE ATT&CK framework under technique T1078, Valid Accounts, as it involves an attacker leveraging legitimate but misconfigured credentials to access unauthorized resources. Furthermore, because the flaw allows for modification of content owned by others, it falls under CWE-653, which relates to insufficient isolation between different security contexts or users within a system. Understanding these mappings helps in categorizing the risk and communicating its severity to stakeholders who may not be familiar with specific plugin code but understand broader industry standards.
To mitigate this vulnerability, immediate action is required by updating the GiveWP plugin to version 4.19.0.1 or later, where the developers have corrected the logic for determining page capability requests. Until an update can be applied in environments that cannot undergo immediate patching, administrators should consider restricting access to custom fundraising roles if they are not strictly necessary for all users. Implementing a Web Application Firewall with rulesets tuned to detect anomalous behavior related to post editing and publishing by low-privilege accounts may provide a temporary layer of defense against exploitation attempts. Additionally, regular audits of user capabilities and role assignments should be conducted to ensure that custom roles do not inadvertently inherit excessive permissions from parent classes or default WordPress configurations. Monitoring logs for unusual activity involving page modifications by non-administrative users can also aid in early detection of potential abuse stemming from this flaw.