CVE-2026-119749 in GetPaid Plugin
Summary
by MITRE • 11/04/2026
The GetPaid plugin for WordPress before 2.8.63 contains an improper input validation vulnerability that allows unauthenticated attackers to bypass payment processing by submitting a negative item quantity on a public payment form. Attackers can exploit the unchecked quantity value in process_item() to produce a negative line subtotal that reduces the invoice total to zero, causing process_free_payment() to mark the invoice as paid without any actual gateway charge.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The GetPaid plugin for WordPress prior to version 2.8.63 contains a critical improper input validation vulnerability within its payment processing logic. This flaw specifically affects public-facing payment forms where users submit transaction details, including item quantities and prices. The core of the issue lies in the insufficient sanitization and range checking of numerical inputs provided by unauthenticated visitors. Specifically, the function responsible for processing individual line items fails to enforce positive integer constraints on quantity fields. This oversight allows attackers to manipulate form data before it is processed into financial calculations, creating a pathway for transaction manipulation that bypasses standard security controls designed to prevent unauthorized or fraudulent payments.
The technical mechanism of this exploitation involves submitting a negative value in the item quantity field during checkout. When the application processes these inputs through its internal logic, typically within functions like process_item(), it performs arithmetic operations without validating whether the input represents a legitimate commercial transaction parameter. By injecting a negative number, an attacker can cause the calculated subtotal for that specific line item to become negative rather than positive. This manipulation directly impacts the aggregate calculation of the invoice total. When this artificially reduced or zeroed-out total is passed to the subsequent payment processing stage, specifically within functions such as process_free_payment(), the system interprets a zero balance as an indication that no further action is required from external payment gateways. Consequently, the application marks the order status as paid without initiating any actual financial transaction with banking partners or third-party processors like Stripe or PayPal.
The operational impact of this vulnerability is severe for businesses relying on WordPress and GetPaid to manage e-commerce operations. Attackers can effectively obtain goods or services for free by exploiting this logic flaw, leading directly to revenue loss and inventory depletion. Beyond the immediate financial damage, such exploitation undermines customer trust in the platform's security integrity. If left unpatched, malicious actors could automate these requests at scale, causing significant operational disruption and potentially triggering fraud detection alerts from legitimate payment processors due to anomalous transaction patterns that appear as zero-value completions. This represents a classic case of business logic abuse where the application fails to enforce domain-specific rules regarding valid input ranges for financial data.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-862 Missing Authorization in certain contexts if the form was intended to be restricted, though it primarily stems from inadequate validation of numerical constraints leading to CWE-754 Improper Check for Unusual or Exceptional Conditions. In terms of attack vectors, this falls under ATT&CK technique T1190 Exploit Public-Facing Application and specifically relates to manipulating application logic to bypass payment mechanisms. The vulnerability highlights the importance of strict type checking and range validation on all user-supplied numerical data that influences financial calculations.
To mitigate this risk, administrators must immediately upgrade the GetPaid plugin to version 2.8.63 or later where these input validations have been corrected. Developers should implement robust server-side validation for all quantity fields, ensuring they are strictly positive integers before any arithmetic operations occur. Additionally, integrating client-side validation with corresponding server-side checks provides defense in depth against such manipulation. It is also advisable to review other forms within the application that handle numerical inputs related to pricing or quantities to ensure similar vulnerabilities do not exist elsewhere in the codebase. Regular security audits and penetration testing focused on business logic flaws are recommended to identify and remediate similar issues before they can be exploited by malicious actors seeking to circumvent payment systems.