CVE-2026-110653

Executive Summary

CVE-2026-110653 is an authentication bypass via a time-of-check-to-time-of-use (TOCTOU) race condition in the LatePoint Appointment Booking WordPress plugin, affecting all versions up to and including 5.7.4. The OTP verification attempt counter is updated non-atomically, allowing an unauthenticated attacker who knows a victim's registered email or phone number to send concurrent requests that defeat the 10-attempt lockout and brute-force the 6-digit one-time code. Successful exploitation yields full account takeover of the targeted customer account with a 9.1 CVSS score (High confidentiality and integrity impact). No patch, public proof-of-concept, or exploit code has been identified at time of writing.

Technical Analysis

LatePoint ships a one-time-password (OTP) based authentication flow used to verify a customer's identity during booking and account access. The flow involves two sides:

• Unauthenticated endpoints (request_otp and resend_otp) that issue an OTP code to a customer's registered email address or phone number and publicly emit a WordPress nonce (otp_verify_otp_nonce).
• A verification endpoint (auth__verify_otp), handled by the verifyOTP function, that validates the submitted 6-digit code against the stored code.

The flaw is a non-atomic read-modify-write on the OTP verification-attempts counter. When verifyOTP processes a request, it reads the current attempts value from the database into memory, increments it in application logic, and then writes the new value back. Two safeguards that would normally prevent brute force are absent:

1. The UPDATE statement carries no conditional WHERE attempts < 10 guard, so it does not atomically reject writes once the cap is reached.
2. There is no SELECT ... FOR UPDATE row-level lock, so concurrent requests do not serialize on the counter row.

This creates a TOCTOU window: when an attacker fires many concurrent auth__verify_otp requests, each request reads the same or a stale in-memory attempts value (typically 0 or a low number), increments it to a value that still appears to be below the 10-attempt lockout threshold, and writes it back. The increments overwrite one another instead of accumulating, so the effective attempt cap of 10 is never enforced. The attacker effectively obtains an unbounded number of OTP guesses in a single window against a 6-digit space (1,000,000 possible codes).

The WordPress nonce check (otp_verify_otp_nonce) does not mitigate the issue because it is not a security control against an unauthenticated attacker in this context: the same nonce is emitted by the unauthenticated request_otp and resend_otp endpoints, so any attacker can trivially obtain a valid nonce before launching the race. The nonce provides CSRF protection semantics, not authentication or rate-limiting.

Root cause maps to CWE-287 (Improper Authentication): the OTP verification logic fails to enforce its own lockout policy under concurrent access, and the OTP itself is a low-entropy secret (6 digits) whose protection depends entirely on that lockout. The absence of a database-level lock or atomic conditional UPDATE is the precise implementation gap.

Exploitation Scenarios

No public PoC is available; the attack chain below is derived strictly from the vulnerability class (authentication bypass via race condition on an OTP attempt counter) and the endpoints and function named in the NVD description.

1. Reconnaissance / target identification. The attacker identifies a WordPress site running the LatePoint plugin (all versions ≤ 5.7.4). The attacker needs a victim identifier: a target customer's registered email address or phone number. This is often discoverable through public booking flows, staff directories, or prior enumeration. The attacker also confirms the plugin's OTP endpoints are reachable.

2. Nonce acquisition. Pre-launch, the unauthenticated attacker calls the public request_otp and/or resend_otp endpoints, which publicly emit the otp_verify_otp_nonce. This valid nonce is then reused on the verification requests, so the nonce check is satisfied without any authentication.

3. Triggering the race. The attacker sends a large number of concurrent HTTP requests to the auth__verify_otp endpoint, each carrying a different candidate 6-digit OTP. Because verifyOTP performs a non-atomic read-modify-write on the attempts counter with no WHERE attempts < 10 guard and no SELECT ... FOR UPDATE lock, concurrent requests all observe a stale attempts value. The increments collide and overwrite each other, so the 10-attempt lockout is never triggered. The attacker thereby gets many guesses within the TOCTOU window instead of being locked out after 10.

4. Brute force and account takeover. Iterating concurrent batches across the 6-digit space allows the attacker to search for the correct code much faster than the lockout intends. On a hit, the session authenticates as the targeted LatePoint customer.

5. Post-exploitation. The attacker gains full access to the victim's LatePoint customer account: bookings, booking history, and personal data associated with the account. Because this is a WordPress-integrated plugin, account context may expose customer PII (names, contact details, appointment data) and, depending on configuration, business scheduling information. There is no direct evidence in the provided data of code execution or privilege escalation beyond the customer account scope.

Key dependency: the attack requires concurrent request throughput able to outpace counter serialization, and a known victim identifier and/or ability to request a fresh OTP for that identifier.

Impact Assessment

• Confidentiality (High): Full read access to the targeted customer's account, bookings, and personal data.
• Integrity (High): The attacker can act as the customer — create, modify, or cancel bookings and alter account-associated data.
• Availability (None per vector): No direct denial-of-service impact specified.
• Scope (Unchanged), Privileges Required (None), User Interaction (None), Attack Complexity (Low per vector): The attack is network-reachable and requires no credentials or user action. (Note: a race condition is operationally timing-dependent, but the published vector rates AC:L.)

Business impact: unauthorized access to customer PII and appointment data constitutes a privacy/regulatory exposure (e.g., GDPR/CCPA obligations for booking businesses). Blast radius spans all customers whose email or phone identifier the attacker knows; a large booking site could expose many accounts. The CVSS base score is 9.1 (Critical). EPSS has not been scored by FIRST.org. CISA KEV status: not listed.

Detection Guidance

Sigma Rule

title: LatePoint OTP Verification Race / Brute Force Attempt
id: 8f3c2a71-9b4e-4d2a-a1f6-latepointotp01
status: experimental
description: Detects high-volume or concurrent requests to LatePoint auth__verify_otp endpoint indicative of OTP brute-force via race condition (CVE-2026-110653).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-110653
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-method: 'POST'
    cs-uri-query|contains: 'auth__verify_otp'
  selection_otp_param:
    cs-uri-query|contains: 'otp'
  timeframe: 60s
  condition: selection_endpoint and selection_otp_param | count() by src_ip > 20
fields:
  - src_ip
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate user retry storms
  - Load testing
level: high

YARA Rule

rule LatePoint_OTP_Race_CVE_2026_110653
{
    meta:
        description = "Detects LatePoint plugin code paths associated with the OTP verification race condition (CVE-2026-110653)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-110653"
        date = "2026-01-01"
    strings:
        $fn1 = "function verifyOTP" nocase ascii
        $fn2 = "verifyOTP(" nocase ascii
        $ep1 = "auth__verify_otp" nocase ascii
        $ep2 = "request_otp" nocase ascii
        $ep3 = "resend_otp" nocase ascii
        $nonce = "otp_verify_otp_nonce" nocase ascii
        $att = "attempts" nocase ascii
    condition:
        filesize < 5MB and
        (uint16(0) == 0x3C3F or $fn1 or $ep1) and
        $fn2 and $ep1 and 1 of ($ep2, $ep3, $nonce) and $att
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-110653 LatePoint OTP Verification Brute Force Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"auth__verify_otp"; http.uri; content:"otp"; threshold: type both, track by_src, count 20, seconds 60; classtype:attempted-user; reference:cve,2026-110653; sid:2026110653; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=60s
  [ network where http.request.method == "POST" and stringContains(http.request.uri, "auth__verify_otp") ]
  [ network where http.request.method == "POST" and stringContains(http.request.uri, "auth__verify_otp") ]
  [ network where http.request.method == "POST" and stringContains(http.request.uri, "auth__verify_otp") ]

Populate within an EQL search across logs-* or web access logs; tune the sequence count and maxspan to match site baseline. High counts of auth__verify_otp from one source.ip in a short window indicate brute-force/race attempts.

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=nginx
("auth__verify_otp" OR "*verify_otp*")
| eval user_ip=coalesce(src_ip, clientip)
| bin _time span=60s
| stats count AS attempts values(uri) AS uris dc(uri) AS distinct_uris by user_ip _time
| where attempts > 20
| sort - attempts

Wazuh OSSEC Rule

<group name="web,latepoint,cve-2026-110653,">
  <rule id="1106530" level="10" frequency="20" timeframe="60">
    <if_matched_sid>31103</if_matched_sid>
    <match>auth__verify_otp</match>
    <description>CVE-2026-110653: Possible LatePoint OTP brute-force/race condition (excessive auth__verify_otp requests from same source)</description>
    <same_source_ip />
    <mitre>
      <id>T1110.001</id>
    </mitre>
    <group>authentication_failures,brute_force,</group>
  </rule>
  <rule id="1106531" level="6">
    <match>auth__verify_otp</match>
    <description>LatePoint OTP verification request observed</description>
    <group>latepoint_otp,</group>
  </rule>
</group>

Note: parent rule 31103 is the standard web accesslog rule; adjust the matched parent to your Wazuh web log decoder as needed.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix is available for versions up to and including 5.7.4.

1. Immediate mitigations

   • Restrict or disable OTP-based customer authentication in the LatePoint plugin until a fix is available; fall back to authenticated login or administrative provisioning if operationally feasible.
   • Place the WordPress site behind a WAF or reverse proxy and rate-limit /wp-admin/admin-ajax.php (and any path handling auth__verify_otp) per source IP and per targeted identifier — e.g., cap requests to request_otp, resend_otp, and auth__verify_otp to a low threshold over a short window.
   • Implement server-side concurrency limiting (e.g., per-IP connection caps or a queue) for OTP verification requests to reduce the window for parallel brute force.
   • Monitor and alert on high-volume auth__verify_otp traffic (see detection rules) and on OTP resends to the same account.
   • If the plugin is not essential, disable and remove it.

2. Patch / upgrade steps

   • Track the LatePoint plugin changelog and the vendor's site for a release beyond 5.7.4 that addresses the TOCTOU counter flaw. No patch reference exists in tracked sources at this time.
   • When a fix is released, upgrade promptly; verify the fix implements an atomic conditional UPDATE ... WHERE attempts < 10 or a SELECT ... FOR UPDATE row lock.
   • Interim: apply a virtual patch/WAF rule that blocks or throttles auth__verify_otp brute-force patterns.

3. Long-term hardening

   • Enforce OTP attempt caps atomically at the database layer (conditional UPDATE or row lock) and audit all authentication counters for similar non-atomic patterns.
   • Increase OTP entropy (longer codes or numeric+alphanumeric) and add per-identifier throttling, not only per-IP.
   • Treat nonces as CSRF controls rather than authentication controls; never rely on a nonce as a rate limit.
   • Maintain an SBOM/inventory of WordPress plugins and subscribe to plugin vulnerability feeds.
   • Log and alert on OTP verification failures and resends; retain web logs for forensic review.

References

• NVD — CVE-2026-110653: https://nvd.nist.gov/vuln/detail/CVE-2026-110653
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1110.001 — Brute Force: Password Guessing: https://attack.mitre.org/techniques/T1110/001/
• FIRST EPSS (score not yet available for this CVE): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-110653 not currently listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog