CVE-2026-100163 in Appointment Booking Plugin – LatePoint Plugin
Summary
by MITRE • 10/14/2026
The Appointment Booking Plugin – LatePoint | Calendar & Scheduling for WordPress plugin for WordPress is vulnerable to Authentication Bypass in versions up to, and including, 5.7.2 via the OsCustomerHelper::create_wp_user_for_customer() helper reached from the public process_step_customer() booking step. When the 'Use WordPress users as customers' option is enabled, the helper falls back from email_exists() to username_exists( $customer->email ), which matches any WordPress user whose user_login equals the victim customer's email even when that user's user_email is completely different, and links that WordPress user's ID into the victim's LatePoint customer row (only privileged roles are excluded; Subscriber is allowed). This makes it possible for authenticated attackers, with Subscriber-level access and above, to take over another customer's LatePoint account — accessing their bookings, service, agent, and calendar data, and having the victim customer's email overwritten with the attacker's on next login — by holding a Subscriber account whose user_login equals the victim's email and submitting an unauthenticated public booking step registration request.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in LatePoint versions up to 5.7.2 represents a critical authentication bypass flaw rooted in improper handling of user identity mapping within WordPress integration logic. The core technical defect resides in the OsCustomerHelper::create_wp_user_for_customer() function, which is invoked during the public process_step_customer booking workflow. When the plugin configuration enables the use of existing WordPress users as customers, the system attempts to link a LatePoint customer record to an associated WordPress user account. However, the implementation contains a logical error where it prioritizes matching against the username field rather than the email address. Specifically, after failing to find a match via email_exists(), the code falls back to checking if a user exists with a login name equal to the provided email address using username_exists($customer->email). This approach fundamentally misunderstands how WordPress distinguishes between users, as it allows an attacker to hijack any account where the user_login field coincidentally matches another user's email address.
This architectural flaw enables authenticated attackers possessing at least Subscriber-level privileges to perform a complete takeover of other customers' LatePoint accounts. By creating or utilizing a WordPress account with a username that exactly matches the target victim's email address, an attacker can submit unauthenticated booking requests through the public-facing interface. The system incorrectly associates the existing customer data belonging to the victim with the attacker's controlled WordPress user ID. This linkage grants the attacker immediate access to sensitive information including past bookings, service preferences, agent assignments, and calendar availability associated with the victim's profile. Furthermore, because the integration ties identity directly to this flawed mapping mechanism, subsequent login attempts by the actual owner of the email address may result in their credentials being overwritten or misdirected, effectively locking them out while consolidating control under the attacker's account.
From a security classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-640 Weak Password Recovery Mechanisms for Forgotten Passwords, as it allows unauthorized access through identity confusion rather than credential compromise. In terms of offensive tactics, this behavior mirrors ATT&CK technique T1098.003 Account Manipulation: Additional Cloud Roles or Permissions, where an adversary manipulates account associations to gain elevated privileges and persistent access within the application environment. The impact is severe because it bypasses standard authentication checks by exploiting a logic error in user provisioning rather than breaking cryptographic protections or stealing secrets directly.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately update LatePoint to version 5.7.3 or later, where this logical flaw has been corrected to ensure that email addresses are used as the primary unique identifier for user matching rather than usernames. Until an upgrade is possible, site administrators can disable the option to use WordPress users as customers within the plugin settings, forcing all bookings to remain isolated from core WordPress identity systems and preventing the cross-contamination of accounts. Additionally, enforcing strict validation on username fields during registration can reduce the likelihood of attackers creating accounts with usernames that mimic other users' email addresses, although this is a secondary defense compared to patching the underlying code logic. Regular auditing of user roles and monitoring for unexpected associations between customer records and WordPress user IDs can also help detect any successful exploitation attempts early in their lifecycle.