CVE-2026-85530 in GiveWP Plugin
Summary
by MITRE • 09/16/2026
The GiveWP WordPress plugin before 4.16.8.1 does not consistently normalise a donor's e-mail address between the value it stores and the value it later uses to look that donor up, allowing unauthenticated users to be resolved as an arbitrary donor and to set the WordPress password of any user account linked to one, including an administrator's.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in GiveWP versions prior to 4.16.8.1 represents a critical authentication bypass mechanism rooted in inconsistent data normalization practices within the plugin’s donor lookup logic. This flaw allows unauthenticated attackers to manipulate email address inputs during password reset or donation-related processes, leading to account takeover of arbitrary WordPress users, including those with administrative privileges. The core issue lies in how the application handles string comparison and storage for email addresses associated with donors. When a user initiates an action that requires identifying them by their email address, such as resetting a password via the GiveWP interface or potentially through other integrated forms, the system performs lookups against its database of registered donors. However, there is a discrepancy between how the email address provided in the request is processed for lookup purposes versus how it was originally stored when the donor profile was created.
This inconsistency typically stems from differences in case sensitivity and whitespace handling during input validation and storage operations. Email addresses are generally considered case-insensitive according to RFC 5321, but many systems store them with specific casing or trim leading and trailing spaces inconsistently across different code paths. In this vulnerability scenario, the lookup function may normalize the incoming email address by converting it to lowercase and stripping whitespace before querying the database, while the stored value retains its original case or includes hidden characters that were not stripped during initial registration. Alternatively, the storage process might have failed to properly sanitize the input at the time of donor creation, resulting in a mismatch between the canonical form expected for lookup and the actual data persisted in the database. This divergence creates an opportunity for attackers to exploit the gap by providing an email address that matches the normalized version used for searching but differs slightly from the stored value, or vice versa, depending on which side fails to enforce strict normalization.
The operational impact of this vulnerability is severe due to its unauthenticated nature and broad scope. An attacker does not need valid credentials to initiate the attack sequence; they only require knowledge of a target email address associated with any donor account in the GiveWP system. By submitting specific variations of that email address, an attacker can trick the application into associating their password reset request or other sensitive actions with the wrong user profile. If successful, this allows the attacker to gain control over the victim’s WordPress account. Since GiveWP is often used on sites where administrators manage donations and donor data, compromising an administrator account provides full control over the entire website. This includes access to sensitive financial records, customer personal information, plugin configurations, and the ability to install malicious plugins or modify site code, effectively leading to a complete compromise of the web application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, specifically regarding failures in normalizing input data before processing it for security-critical operations such as authentication lookups. It also relates closely to CWE-643 Improper Mitigation for XPATH Injection issues if the underlying database query mechanism is susceptible to injection due to malformed inputs, though the primary vector here is logic-based rather than syntax-based. In terms of MITRE ATT&CK framework mapping, this behavior facilitates Account Manipulation and Credential Access techniques. Specifically, it enables an attacker to perform Password Spraying or Brute Force attacks more effectively by targeting specific high-value accounts through email enumeration and subsequent password reset abuse. The lack of consistent normalization acts as a logic flaw that undermines the integrity of identity verification processes within the plugin’s workflow.
Mitigation strategies must address both immediate remediation and long-term defensive coding practices. The primary solution is to upgrade GiveWP to version 4.16.8.1 or later, where this inconsistency has been corrected by enforcing strict normalization rules across all code paths involved in donor identification. This includes ensuring that email addresses are consistently lowercased and stripped of whitespace both upon storage and during subsequent lookups. For organizations unable to immediately upgrade, temporary mitigations include restricting access to GiveWP forms via IP whitelisting if feasible, or implementing a Web Application Firewall rule that detects anomalous patterns in password reset requests associated with donor emails. Additionally, administrators should enforce strong password policies and enable multi-factor authentication for all user accounts, particularly those with administrative roles, to reduce the impact of any potential credential compromise resulting from this vulnerability. Regular audits of input validation logic across custom plugins are recommended to prevent similar normalization discrepancies in other parts of the application stack.