CVE-2026-94432 in Appointment Booking Plugin
Summary
by MITRE • 10/02/2026
The Appointment Booking Plugin – LatePoint | Calendar & Scheduling for WordPress plugin for WordPress is vulnerable to Insecure Direct Object Reference in versions up to, and including, 5.7.1 via the OsPaypalConnectController::create_order_for_transaction() action registered as a public (unauthenticated) route through wp_ajax_nopriv_latepoint_route_call. The handler loads an OsInvoiceModel by a sequential integer 'invoice_id' with no access-key/UUID or ownership check (the sibling Stripe and Razorpay handlers require a 128-bit access-key UUID via OsInvoicesHelper::get_invoice_by_key), and then calls OsTransactionIntentHelper::create_or_update_transaction_intent() which persists a transaction intent tied to the target invoice's customer_id, order_id and charge_amount and regenerates its intent_key before the PayPal-configured guard is reached. This makes it possible for unauthenticated attackers to enumerate invoices belonging to arbitrary customers, create unauthorized transaction-intent rows linked to another customer's data, and overwrite the intent_key of any in-flight NEW-status transaction intent — invalidating the intent_key that legitimate Stripe/Razorpay flows are waiting on and breaking payment webhooks for those customers.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified within the LatePoint Appointment Booking Plugin for WordPress represents a critical failure in access control mechanisms, specifically classified as an Insecure Direct Object Reference or IDOR under CWE-639. This flaw exists in versions up to and including 5.7.1 and is triggered through the OsPaypalConnectController::create_order_for_transaction() action. The endpoint is registered as a public route via wp_ajax_nopriv_latepoint_route_call, meaning it does not require any form of authentication or user session validation to be accessed by external actors. This architectural decision exposes sensitive backend logic directly to unauthenticated internet traffic without the necessary safeguards that are present in other payment gateway handlers within the same plugin ecosystem.
The core technical flaw lies in how the application retrieves invoice data for processing payments. When an attacker invokes this endpoint, they can supply a sequential integer representing an invoice_id parameter. The system loads the corresponding OsInvoiceModel directly using this identifier without performing any ownership verification or access-key validation. In contrast, other payment integrations such as Stripe and Razorpay within LatePoint utilize a more secure approach by requiring a 128-bit access key UUID via the OsInvoicesHelper::get_invoice_by_key method to retrieve invoice details. The absence of such cryptographic identifiers in the PayPal handler allows attackers to iterate through sequential integer values, effectively enabling them to enumerate invoices belonging to arbitrary customers who have previously used the service.
Beyond simple enumeration, this vulnerability facilitates more severe malicious actions involving transaction manipulation. Once an attacker identifies a valid invoice_id, they can invoke the OsTransactionIntentHelper::create_or_update_transaction_intent() function. This operation persists a new or updates an existing transaction intent row linked to the target customer's data, including their customer_id, order_id, and charge_amount. Crucially, this process regenerates the intent_key associated with the invoice before any PayPal-specific configuration guards are evaluated. The timing of this regeneration is particularly dangerous because it occurs prior to the validation checks that would normally restrict access based on payment method settings or user permissions.
The operational impact of this vulnerability extends beyond data exposure into active service disruption and potential financial fraud. By overwriting the intent_key of any transaction in a NEW status, an attacker can invalidate the cryptographic token that legitimate Stripe or Razorpay payment flows are waiting to complete their webhook processing. This action effectively breaks the payment workflow for affected customers, causing transactions to fail silently or hang indefinitely as they await a key that no longer matches the server-side state. Furthermore, attackers could potentially create unauthorized transaction intents linked to other users' data, which may lead to confusion in order tracking systems and complicate dispute resolution processes for merchants relying on accurate financial records.
From an offensive security perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Collection via Client Side Software or potential T1530 Data from Local System Archives if the enumerated data includes sensitive customer information stored within the invoice models. The ability to manipulate transaction states and keys also touches upon aspects of Integrity Violations where an attacker alters system state without authorization. For organizations utilizing this plugin, immediate mitigation is required given the unauthenticated nature of the exploit vector.
To mitigate this risk, administrators should immediately update the LatePoint plugin to a version later than 5.7.1 if such a patch has been released by the vendor. If an update is not yet available, temporary mitigations include restricting access to WordPress AJAX endpoints that handle payment processing through web application firewall rules or server-level configurations. It is also advisable to audit database logs for unusual patterns of sequential invoice_id requests which may indicate active exploitation attempts. Ensuring that all future development follows the security model used by Stripe and Razorpay integrations, specifically requiring UUID-based access keys rather than simple integer identifiers for sensitive operations, will prevent similar vulnerabilities from being introduced in subsequent updates.