The Appointment Booking Plugin – LatePoint | Calendar & Scheduling for WordPress plugin for WordPress is vulnerable to Authentication Bypass via Race Condition in all versions up to, and including, 5.7.4. This is due to a non-atomic read-modify-write on the OTP verification attempts counter in the verifyOTP function: the counter is incremented using a stale in-memory value with no conditional WHERE attempts < 10 guard on the UPDATE and no SELECT ... FOR UPDATE row lock, creating a TOCTOU window that allows concurrent requests to bypass the 10-attempt lockout. This makes it possible for unauthenticated attackers — who know a target customer's registered email address or phone number — to fire concurrent requests to the authverifyotp endpoint, defeat the lockout cap, brute-force the 6-digit OTP code, and authenticate as the targeted LatePoint customer, gaining full access to their account, bookings, and personal data. The nonce check present on the endpoint (otpverifyotpnonce) does not mitigate this issue, as the nonce is publicly emitted by the unauthenticated requestotp and resendotp endpoints and is trivially obtainable by any unauthenticated attacker prior to launching the race.

The Appointment Booking Plugin – LatePoint | Calendar & Scheduling for WordPress plugin for WordPress is vulnerable to generic SQL Injection via 'booking[serviceid]' Parameter in all versions up to, and including, 5.7.2 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

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::createorderfortransaction() action registered as a public (unauthenticated) route through wpajaxnoprivlatepointroutecall. The handler loads an OsInvoiceModel by a sequential integer 'invoiceid' with no access-key/UUID or ownership check (the sibling Stripe and Razorpay handlers require a 128-bit access-key UUID via OsInvoicesHelper::getinvoicebykey), and then calls OsTransactionIntentHelper::createorupdatetransactionintent() which persists a transaction intent tied to the target invoice's customerid, orderid and chargeamount and regenerates its intentkey 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 intentkey of any in-flight NEW-status transaction intent — invalidating the intentkey that legitimate Stripe/Razorpay flows are waiting on and breaking payment webhooks for those customers.