Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-02T08:17:03.587Z",
  "pubdate": "2026-10-02T08:17:03.587Z",
  "executiveSummary": "The Appointment Booking Plugin – LatePoint for WordPress contains an Insecure Direct Object Reference (IDOR) vulnerability in versions up to and including 5.7.1. This flaw exists within the OsPaypalConnectController::create_order_for_transaction() action, which is exposed to unauthenticated users via the wp_ajax_nopriv_latepoint_route_call WordPress hook.\nThe vulnerability allows an unauthenticated attacker to bypass access controls to manipulate transaction intent data associated with arbitrary customer invoices. Because the application fails to validate ownership or require a cryptographically secure access-key for PayPal-related requests—unlike the implemented security patterns for Stripe and Razorpay—attackers can enumerate invoice IDs and modify transaction states.\nThe impact includes unauthorized creation of transaction-intent rows linked to sensitive customer data and the disruption of legitimate payment workflows. By overwriting existing intent_keys, an attacker can invalidate in-flight payment sessions, effectively causing a denial-of-service for specific customer transactions and breaking payment webhooks. This vulnerability poses a significant risk to data integrity and business operations, as it allows for the unauthorized manipulation of payment-related objects without requiring administrative or user authentication.",
  "technicalDetails": "The root cause of this vulnerability is the improper implementation of access control in the OsPaypalConnectController::create_order_for_transaction() method. While other payment gateways in the LatePoint plugin, specifically Stripe and Razorpay, utilize the OsInvoicesHelper::get_invoice_by_key method to verify ownership via a 128-bit access-key UUID, the PayPal controller accepts a sequential integer invoice_id directly from the user request without any validation.\nThe vulnerable component is registered as a public-facing route via wp_ajax_nopriv_latepoint_route_call, making it accessible over the network to any unauthenticated remote attacker. The attack flow begins with the attacker supplying an integer invoice_id to the endpoint. The application then proceeds to load the corresponding OsInvoiceModel without checking if the requester has permissions to access or modify the record.\nOnce the invoice is loaded, the controller invokes OsTransactionIntentHelper::create_or_update_transaction_intent(). This function performs two critical actions: it persists a transaction intent tied to the target invoice's customer_id, order_id, and charge_amount, and it regenerates the intent_key. Critically, this regeneration occurs before the system checks the PayPal-configured guard, allowing the state change to commit.\nExploitation allows an attacker to perform mass enumeration of invoices by iterating through sequential integer values for the invoice_id parameter. Because the application logic overwrites the existing intent_key for any transaction in a 'NEW' status, an attacker can intentionally disrupt legitimate payment flows. When a legitimate user attempts to complete a payment via Stripe or Razorpay, the expected intent_key will have been invalidated or altered by the malicious PayPal-route request, resulting in failed webhook processing and a breakdown of the transaction state machine.\nThis vulnerability highlights a critical failure in enforcing consistent authorization patterns across different payment provider implementations within the plugin. The lack of cryptographic verification (UUID) for PayPal requests, combined with predictable, sequential identifiers, enables complete unauthorized access to transaction objects, facilitating both information disclosure and service disruption at the transaction management level."
}