CVE-2026-111974 in GiveWP Plugin
Summary
by MITRE • 10/26/2026
The GiveWP WordPress plugin before 4.19.0.1 does not restrict the currency of a donation to the one the site or form accepts, while comparing its amount limits as bare numbers, allowing unauthenticated users to make donations below a form's configured minimum or fixed amount.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified in GiveWP versions prior to 4.19.0.1 represents a critical logic flaw within the donation processing mechanism of this widely used WordPress plugin. The core issue stems from an insufficient validation strategy when handling currency-specific constraints and monetary thresholds. Specifically, the application fails to enforce that donations must adhere to the minimum amount limits defined for the specific currency being utilized in a transaction. Instead of performing context-aware comparisons that account for currency codes or localized numeric formats, the system compares donation amounts as bare numerical values without considering the associated currency unit. This architectural oversight creates a significant security gap that allows unauthenticated users to bypass configured financial restrictions and submit donations below the intended minimum threshold or fixed amount set by site administrators.
From a technical perspective, this flaw is classified under CWE-20 Improper Input Validation, as the application does not adequately sanitize or validate user-supplied input against expected business logic rules. The vulnerability also aligns with CWE-841 Improvement of Insufficient Enforcement of Business Rules, where the software fails to properly enforce constraints that are critical for maintaining data integrity and operational consistency. By treating monetary values as simple integers without validating them against currency-specific limits, the plugin exposes itself to manipulation by attackers who can exploit this discrepancy to perform actions that should be prohibited by the site's configuration. This lack of robust validation allows malicious actors to circumvent financial controls designed to prevent low-value transactions or spam donations, which are often used to clutter databases or test system boundaries for further exploitation.
The operational impact of this vulnerability is multifaceted, affecting both security posture and administrative efficiency. Unauthenticated attackers can exploit this flaw to submit numerous small-donation requests that fall below the configured minimums. This behavior can lead to database bloat due to the accumulation of invalid transaction records, increasing storage requirements and potentially degrading site performance over time. Furthermore, it undermines the integrity of financial reporting by introducing erroneous data into donation logs. For organizations relying on GiveWP for fundraising or membership management, this flaw compromises trust in the system's ability to enforce rules consistently. It also opens the door for potential abuse where attackers might use these low-value transactions as a vector for denial-of-service attacks against payment gateways or internal processing systems by generating excessive transaction volume that bypasses standard rate-limiting mechanisms tied to minimum thresholds.
Mitigation strategies must prioritize immediate patching and enhanced input validation practices. The primary remediation is to upgrade the GiveWP plugin to version 4.19.0.1 or later, where this logic flaw has been addressed by implementing stricter currency-aware validation checks during the donation submission process. Administrators should ensure that their WordPress environment remains updated with all security patches applied promptly. In addition to patching, it is advisable to implement server-side rate limiting and CAPTCHA mechanisms on public-facing forms to mitigate potential abuse from unauthenticated users attempting to exploit this or similar vulnerabilities. Security monitoring tools should be configured to detect anomalous patterns of low-value transaction submissions that deviate from normal user behavior, providing an additional layer of defense against exploitation attempts while the underlying code vulnerability is being resolved through updates.