The GetPaid WordPress plugin from 2.8.63 to 2.8.64 does not ensure item quantities on its payment forms are whole numbers, allowing unauthenticated users to have an invoice for a priced item marked as paid without being charged.

The GetPaid plugin for WordPress before 2.8.63 contains an authorization bypass vulnerability that allows unauthenticated attackers to access and manipulate another user's invoice by supplying its ID through the maybeuseinvoice parameter in processinvoice(), bypassing the ownership and key checks performed by isauthorizedtopay(). Attackers can submit a known pending invoice ID via maybeuseinvoice to read checkout pricing details and initiate a checkout workflow, resulting in an unauthorized state change of the invoice to on-hold.

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 processitem() to produce a negative line subtotal that reduces the invoice total to zero, causing processfreepayment() to mark the invoice as paid without any actual gateway charge.

The GetPaid plugin for WordPress before 2.8.63 contains an incorrect authorization vulnerability where the checkpostpermissions() method in includes/api/class-getpaid-rest-posts-controller.php maps REST operations to generic WordPress post capabilities instead of enforcing the plugin's manageinvoicing permission. Authenticated users with lower-privileged roles such as Editor or Author can exploit this flaw to list other users' invoices, mark pending invoices as paid without recording payment transactions, or create published items and new invoices through the REST API.

WordPress GetPaid Plugin 2.4.6 contains an HTML injection vulnerability that allows authenticated attackers to inject arbitrary HTML code by exploiting the Help Text field in payment forms. Attackers can inject malicious HTML including image tags and scripts into the Help Text field during payment form creation, which gets stored in the database and executed in the browser when the form is viewed.