LatePoint Vulnerability Lets Attackers Bypass OTP Login With a Race Condition (CVE-2026-110653, CVSS 9.1)

One-time passcodes are supposed to be the lock on the door: even if someone knows your email address, they cannot get in without the six-digit code. On October 17, 2026, a disclosure showed how that lock can be picked — not by guessing smarter, but by knocking faster. The LatePoint vulnerability, tracked as CVE-2026-110653 and rated CVSS 9.1 (Critical), is an authentication bypass through a race condition in the OTP verification of the Appointment Booking Plugin – LatePoint | Calendar & Scheduling. The LatePoint vulnerability affects all versions up to and including 5.7.4, and it is fixed in version 5.7.5.

With 100,000+ active installations on WordPress.org, the LatePoint vulnerability reaches a huge population of salons, clinics, consultants, repair shops, and service businesses — sites where customer accounts hold names, phone numbers, booking histories, and personal data. This article explains the LatePoint vulnerability in plain English: what a race condition is, how it defeated the OTP lockout, who is affected, and five proven fixes to secure your bookings now.

What Happened: Inside the LatePoint Vulnerability

Race conditions, explained simply

A race condition is a timing bug. It happens when a program’s correctness depends on the order or timing of events, and an attacker can manipulate that timing. The classic analogy is two people withdrawing from the same bank account at the same instant: if the bank checks the balance, then dispenses cash, then updates the balance — and both withdrawals squeeze between the check and the update — both succeed even though the funds only covered one.

The LatePoint vulnerability is the login-system version of that story. LatePoint protects customer logins with a one-time passcode: the customer requests an OTP, receives a six-digit code, and enters it to authenticate. To stop brute-forcing — simply trying all one million possible six-digit codes — the system enforces a lockout: after 10 failed attempts, the code is dead. Ten attempts against a million possibilities is no threat at all. The LatePoint vulnerability exists because that 10-attempt limit could be defeated by concurrency.

The non-atomic counter

The technical heart of the LatePoint vulnerability is in the verifyOTP function, which manages the attempt counter with a non-atomic read-modify-write sequence. In plain terms, the code does three things in order: read the current attempt count from memory, add one, and write the new count back to the database. The problem is that nothing prevents two requests from interleaving those steps.

Here is what the secure version would do: update the counter with a conditional guard — something like WHERE attempts < 10 on the UPDATE query — and use a row lock (SELECT ... FOR UPDATE) so concurrent requests queue up instead of overlapping. The vulnerable code did neither. The counter was incremented from a stale in-memory value, with no conditional guard on the UPDATE and no row lock. That creates a TOCTOU window — “time of check to time of use” — the textbook name for the gap between reading a value and acting on it, during which the world can change.

How the attack works

With the TOCTOU window open, an unauthenticated attacker who knows a target customer’s registered email address or phone number — information that is often public or easily obtained — can fire many concurrent requests at the auth__verify_otp endpoint. Each request reads the same stale attempt count, each passes the lockout check, and each gets its guess evaluated. The 10-attempt cap, which assumed requests arrive one at a time, is defeated by parallelism: the attacker can effectively try far more than 10 codes, brute-forcing the six-digit OTP until one succeeds. A successful guess authenticates the attacker as the targeted LatePoint customer, with full access to their account, bookings, and personal data.

Why the nonce did not help

Endpoints like this one are normally guarded by a nonce — a token that proves the request came from a legitimate page on the site. The auth__verify_otp endpoint does have a nonce check (otp_verify_otp_nonce). But the LatePoint vulnerability disclosure notes that this check does not mitigate the issue, because the nonce is publicly emitted by the unauthenticated request_otp and resend_otp endpoints. Any visitor can request an OTP — that is the feature working as intended — and in doing so receive a valid nonce. The attacker simply collects the nonce first, then launches the race. A lock whose key is handed to everyone is not a lock.

Disclosure status

The LatePoint vulnerability was publicly disclosed on October 17, 2026. As of disclosure, no public proof-of-concept exploit code has been confirmed, and the CVE is not recorded in the CISA Known Exploited Vulnerabilities catalog as actively exploited. The vulnerable code is documented down to file and function in the plugin’s SVN history — lib/controllers/auth_controller.php, lib/helpers/otp_helper.php, lib/models/model.php in the 5.7.4 tag — with the fix visible in the 5.7.5 tag.

Who Is Affected by the LatePoint Vulnerability

Affected versions: The Appointment Booking Plugin – LatePoint | Calendar & Scheduling, all versions up to and including 5.7.4.

Fixed version: LatePoint 5.7.5, which addresses the OTP verification logic.

Population: WordPress.org reports 100,000+ active installations. Booking plugins are used by service businesses whose customer accounts contain personal data — names, phone numbers, email addresses, appointment histories, and sometimes payment-adjacent information.

Who is at risk in practice: Any LatePoint customer account is a potential target, because the attack only needs the victim’s registered email or phone number. High-profile or high-value customers — and the business owners’ own accounts — are the most attractive targets, but the technique works against any account.

How to check your version

In your WordPress dashboard, go to Plugins → Installed Plugins and find the LatePoint booking plugin. If the version is 5.7.4 or lower, the LatePoint vulnerability applies. Update to 5.7.5 from the same screen or from Dashboard → Updates, then confirm the new version number.

Why the LatePoint Vulnerability Matters

1. Concurrency bugs are authentication bugs in disguise

The LatePoint vulnerability is a reminder that any code guarding authentication must be correct under concurrency, not just in the single-request case the developer imagined. Rate limits, attempt counters, and lockouts are all shared state, and shared state without atomicity is a suggestion, not a control. This is a well-understood class of bug — TOCTOU is decades old — but it keeps appearing in new code because the single-request mental model is so natural. If you build login flows, test them with parallel requests, not just sequential ones.

2. OTP is only as strong as its attempt limit

One-time passcodes are a good authentication factor precisely because the code space is small (one million six-digit codes) and the attempt limit makes brute force infeasible. The LatePoint vulnerability shows what happens when the limit is the weak link: the cryptography of the OTP was fine; the accounting around it was not. For site owners, the lesson is that “we use OTP” is not a complete security statement — the implementation details of the attempt limiting are the actual security boundary.

3. Customer data is the blast radius

A successful LatePoint vulnerability exploit does not give the attacker your WordPress admin — it gives them a customer’s account. That means names, contact details, booking histories, and whatever personal data your booking forms collect. For clinics, salons, and consultants, that data is sensitive by nature, and a breach of customer accounts is a breach of customer trust. Privacy regulations in many jurisdictions treat unauthorized account access as a reportable incident.

4. Public nonces are a design smell

The detail that the OTP nonce is publicly obtainable is worth sitting with. Nonces in WordPress are not secrets — they are per-session, per-action tokens — but an authentication endpoint whose “protection” token is issued to anonymous visitors has a protection that protects nothing. Defense in depth means the attempt limit must hold even when the attacker has a valid nonce, valid session, and unlimited patience. The LatePoint vulnerability is what happens when one layer was secretly load-bearing and nobody checked whether it could bear the load.

What to Do Now: 5 Proven Fixes for the LatePoint Vulnerability

Fix 1: Update LatePoint to 5.7.5 immediately

The patch is the fix. Update the Appointment Booking Plugin – LatePoint to version 5.7.5 from Plugins → Installed Plugins or Dashboard → Updates, and verify the version afterward. The LatePoint vulnerability is a Critical 9.1 affecting customer authentication — treat it as an emergency update, not a routine one.

Fix 2: Review customer accounts and booking logs for suspicious access

Look for signs that the LatePoint vulnerability was probed or exploited before you patched: customer accounts with changed contact details, bookings created or modified at unusual hours, logins from unfamiliar locations or IP addresses, and bursts of OTP verification requests in your server or security logs. Pay particular attention to high-value accounts — your own admin and staff customer profiles first.

Fix 3: Force a fresh authentication posture

Consider requiring customers to re-verify their accounts — for example, by invalidating active sessions so everyone logs in again under the patched code. Notify your customers that you proactively updated your booking system security; transparency about a prompt patch builds more trust than silence. If your business handles sensitive appointments (medical, legal, financial), consider directly advising customers to review their booking histories.

Fix 4: Add a web application firewall with current rules

A WAF with up-to-date rules can detect and block the concurrent-request patterns characteristic of race-condition exploitation — bursts of parallel requests to authentication endpoints. Make sure your security plugin’s firewall is active and its rule set is current; vendors ship signatures for disclosed flaws like the LatePoint vulnerability quickly after disclosure.

Fix 5: Adopt managed maintenance so the next disclosure does not wait

Critical plugin vulnerabilities now arrive weekly. A managed maintenance routine — updates applied within 24–48 hours of disclosure, plus monitoring and backups — turns the LatePoint vulnerability from a crisis into a line item. If you do not have that routine, this disclosure is the reason to get one.

FAQ: LatePoint Vulnerability

Q: What is the LatePoint vulnerability CVE-2026-110653?
A: The LatePoint vulnerability is an authentication bypass via race condition (CVSS 9.1, Critical) in the Appointment Booking Plugin – LatePoint | Calendar & Scheduling, versions up to and including 5.7.4. A non-atomic OTP attempt counter lets unauthenticated attackers fire concurrent requests at the OTP verification endpoint, defeat the 10-attempt lockout, brute-force the six-digit code, and log in as any customer whose email or phone number they know. Disclosed October 17, 2026.

Q: Which LatePoint versions are affected, and what is the fix?
A: All versions up to and including 5.7.4 are affected. The fix is LatePoint 5.7.5. Update immediately and verify the version number afterward.

Q: Is the LatePoint vulnerability being exploited in the wild?
A: As of disclosure, no public proof-of-concept has been confirmed and the CVE is not in CISA’s Known Exploited Vulnerabilities catalog. But the vulnerable functions are publicly documented, so exploitation attempts should be expected — patch during the grace period.

Q: Does the OTP nonce protect against the LatePoint vulnerability?
A: No. The nonce on the verification endpoint is publicly obtainable from the unauthenticated OTP request endpoints, so an attacker can simply collect a valid nonce before launching the race. The attempt limit was the real protection, and the race condition defeated it.

Conclusion

The LatePoint vulnerability is a masterclass in how a subtle timing bug becomes a critical authentication failure. The OTP system was well designed in the sequential case — ten attempts, then lockout — and completely broken in the concurrent case, because the counter was never atomic. One million possible codes is plenty of security when the attacker gets ten guesses; it is no security at all when the attacker gets unlimited parallel guesses. Update to 5.7.5, review your customer accounts, and remember the broader lesson: every rate limit and lockout in your stack must hold under concurrency, or it does not hold at all.

Your customers trusted you with their bookings and their personal data. Qamar Digital Ventures LLC‘s website care plans keep your WordPress site patched, monitored, and backed up — so the next LatePoint vulnerability gets fixed on your site within hours of disclosure, before it becomes your customers’ problem. Visit https://qamardigitalventuresllc.com/ and make security maintenance automatic.

Sources

• TheHackerWire, “CVE-2026-110653: Authentication Bypass – Analysis & Fix” (Oct 17, 2026) — https://www.thehackerwire.com/vulnerability/CVE-2026-110653/
• Wordfence Threat Intelligence, CVE-2026-110653 — https://www.wordfence.com/threat-intel/vulnerabilities/id/61fbc1dd-06c9-409b-8cad-3f350b38dfc3?source=cve
• WordPress.org Plugins SVN, LatePoint browser (auth_controller.php, otp_helper.php, model.php, 5.7.4 tag) — https://plugins.trac.wordpress.org/browser/latepoint/tags/5.7.4/lib/controllers/auth_controller.php