7,000 WordPress Sites Affected by Unauthenticated Critical Vulnerabilities in LatePoint WordPress Plugin

---

🦸 👻 Calling all superheroes and haunters! Introducing the Cybersecurity Month Spooktacular Haunt and the WordPress Superhero Challenge for the Wordfence Bug Bounty Program! Through November 11th, 2024:

• All in-scope vulnerability types for WordPress plugins/themes with >= 1,000 active installations are in-scope for ALL researchers
• Top-tier researchers earn automatic bonuses of between 10% to 120% for valid submissions
• Pending report limits are increased for all
• It’s possible to earn up to $31,200 for high impact vulnerabilities!

---

On September 17, 2024, our Wordfence Threat Intelligence team identified and began the responsible disclosure process for two critical vulnerabilities in the LatePoint plugin, which is estimated to be actively installed on more than 7,000 WordPress websites.

The Unauthenticated Arbitrary User Password Change vulnerability makes it possible for an unauthenticated attacker to change the password of any user, including an administrator, which allows them to take over the account and the website. The Authentication Bypass vulnerability makes it possible for an attacker to gain access to any account on the site, including any administrator accounts.

Wordfence Premium, Wordfence Care, and Wordfence Response users received firewall rules to protect against any exploits targeting these vulnerabilities on September 17, 2024. Sites using the free version of Wordfence receive the same protection 30 days later on October 17, 2024.

We contacted the LatePoint team on September 17, 2024, and received a response the same day. After providing full disclosure details, the developer released the first patch on September 20, 2024, and the second patch on September 24, 2024. We would like to commend the LatePoint team for their prompt response and timely patch.

We urge users to update their sites with the latest patched version of LatePoint, version 5.0.13 at the time of this writing, as soon as possible.

Vulnerability Summary from Wordfence Intelligence

The LatePoint plugin for WordPress is vulnerable to Arbitrary User Password Change via SQL Injection in versions up to, and including, 5.0.11. This is 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 change user passwords and potentially take over administrator accounts. Note that changing a WordPress user’s password is only possible if the “Use WordPress users as customers” setting is enabled, which is disabled by default. Without this setting enabled, only the passwords of plugin customers, which are stored and managed in a separate database table, can be modified.

The LatePoint plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 5.0.12. This is due to insufficient verification on the user being supplied during the booking customer step. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the user id. Note that logging in as a WordPress user is only possible if the “Use WordPress users as customers” setting is enabled, which is disabled by default. The vulnerability is partially patched in version 5.0.12 and fully patched in version 5.0.13.

Technical Analysis #1: Unauthenticated Arbitrary User Password Change via SQL Injection

LatePoint is an appointment scheduling WordPress plugin, which can be used to set up a complete appointment scheduling and booking system on WordPress with many different settings.

Examining the code reveals that the plugin uses the change_password() function in the OsCustomerCabinetController class to handle user password changes via AJAX. The password change requires the password_reset_token parameter, which is a secret value, and is used to identify the user whose password will be changed.

public function change_password(){
  if(OsAuthHelper::is_customer_logged_in()){
    $customer = OsAuthHelper::get_logged_in_customer();
  }elseif($this->params['password_reset_token']){
    $customer = OsCustomerHelper::get_by_account_nonse($this->params['password_reset_token']);
    if(!$customer){
      $response_html = __('Invalid Secret Key', 'latepoint');
      $status = LATEPOINT_STATUS_ERROR;
    }
  }else{
    $status = LATEPOINT_STATUS_ERROR;
    $response_html = __('Error!', 'latepoint');
  }
  if($customer){
    if(!empty($this->params['password']) && $this->params['password'] == $this->params['password_confirmation']){
      if($customer->update_password($this->params['password'])){
        // update connected wp user password
        if(OsAuthHelper::wp_users_as_customers() && $customer->wordpress_user_id){
          global $wpdb;
          $wpdb->update(
              $wpdb->users,
              array(
                  'user_pass'           => $customer->password,
                  'user_activation_key' => '',
              ),
              array( 'ID' => $customer->wordpress_user_id )
          );
        }
        $status = LATEPOINT_STATUS_SUCCESS;
        $response_html = __('Your password was successfully updated.', 'latepoint');

The get_by_account_nonse() function in the OsCustomerHelper class uses the where() function for the query.

public static function get_by_account_nonse( $account_nonse ) {
    if ( empty( $account_nonse ) ) {
        return false;
    }
    $customer = new OsCustomerModel();

    return $customer->where( [ 'account_nonse' => $account_nonse ] )->set_limit( 1 )->get_results_as_models();
}

This where() function adds the conditions for the model.

public function where( $conditions ) {
	if ( empty( $conditions ) ) {
		return $this;
	}
	$this->conditions = array_merge( $this->conditions, $conditions );

	return $this;
}

The build_conditions_query() function in the OsModel class builds the conditions for the query based on the type and contents of the value. The following code, for example, handles the case when the condition is an array:

} elseif ( is_array( $value ) && ( isset( $value['OR'] ) || isset( $value['AND'] ) ) ) {
	// IS ARRAY AND OR
	foreach ( $value as $condition_and_or => $condition_values ) {

		$temp_query  .= '(';
		$sub_queries = [];
		foreach ( $condition_values as $condition_key => $condition_value ) {
			if ( is_string( $condition_key ) && is_string( $column ) ) {
				$temp_key       = $this->with_table_name( $column ) . $condition_key;
				$sub_conditions = [ $temp_key => $condition_value ];
			} elseif ( is_string( $condition_key ) ) {
				$sub_conditions = [ $this->with_table_name( $condition_key ) => $condition_value ];
			} else {
				$sub_conditions = [ $column => $condition_value ];
			}
			$conditions_and_values = $this->build_conditions_query( $sub_conditions, $condition_and_or );
			$sub_queries[]         = $conditions_and_values[0];
			$where_values          = array_merge( $where_values, $conditions_and_values[1] );
		}
		$temp_query .= implode( ' ' . $condition_and_or . ' ', $sub_queries );
		$temp_query .= ')';
	}
}

The most significant problem and vulnerability is caused by the fact that there is no sanitization or escaping on the password_reset_token value, allowing any value to be set, including an array value, which will be handled as an array in the query builder.

This makes it possible for unauthenticated attackers to supply the password_reset_token array parameter, allowing them to create a where condition in the SQL query that uses the user id instead of performing an exact string comparison with the account_nonse. This means that an attacker can bypass the token validation and only use a user id, which is an easily obtainable value, to reset user passwords.

The normal SQL query for the customer “get by account nonse” looks like this:

The exploit SQL query with the injection looks like this:

As with any Arbitrary User Password Change that leads to a Privilege Escalation vulnerability, this can be used for complete site compromise. Once an attacker has gained administrative user access to a WordPress site they can then manipulate anything on the targeted site as a normal administrator could. This includes the ability to upload plugin and theme files, which can be malicious zip files containing backdoors, and modifying posts and pages which can be leveraged to redirect site users to other malicious sites.

We would like to emphasize that this vulnerability only critically affects site owners who have enabled the “Use WordPress users as customers” option in the plugin settings, because the plugin only handles and modifies WordPress users in this case.

Technical Analysis #2: Authentication Bypass

Examining the code reveals that the plugin uses the process_step_customer() function in the OsStepsHelper class to manage new customer registrations during the booking steps.

public static function process_step_customer() {
    $status = LATEPOINT_STATUS_SUCCESS;

    $customer_params = OsParamsHelper::get_param( 'customer' );

$customer->set_data( $customer_params );
if ( $customer->save() ) {

The most significant problem and vulnerability is caused by the fact that there are no restrictions on the customer parameters, which means that even the wordpress_user_id value can be provided.

This makes it possible for unauthenticated attackers to supply the wordpress_user_id customer parameter with any user id, including administrators, during the customer registration. The plugin then automatically authenticates the customer as the associated WordPress user.

Ultimately, this makes it possible for threat actors to bypass authentication and gain access to arbitrary accounts on sites running a vulnerable version of the plugin. As always, authentication bypass vulnerabilities and resulting access to high privileged user accounts, make it easy for threat actors to completely compromise a vulnerable WordPress site and further infect the victim.

Again, this vulnerability also only critically affects site owners who have enabled the “Use WordPress users as customers” option in the plugin settings, because the plugin only handles and authenticates WordPress users in this case.

Disclosure Timeline

September 17, 2024 – Wordfence Threat Intelligence team discovered the Unauthenticated Arbitrary User Password Change and Authentication Bypass vulnerabilities in LatePoint.
September 17, 2024 – Wordfence Premium, Care, and Response users received firewall rules to provide protection against any exploits that may target these vulnerabilities.
September 17, 2024 – We initiated contact with the plugin vendor asking them to confirm the inbox for handling the discussion.
September 17, 2024 – The vendor confirmed the inbox for handling the discussion.
September 17, 2024 – We sent over the full disclosure details for both the Unauthenticated Arbitrary User Password Change and Authentication Bypass​ vulnerabilities.
September 19, 2024 – The vendor acknowledged the report and began working on a fix.
September 20, 2024 – The partially patched version, 5.0.12, was released.
September 24, 2024 – The fully patched version, 5.0.13, was released.
October 17, 2024 – Wordfence Free users receive the same protection.

Conclusion

In this blog post, we detailed an Arbitrary User Password Change vulnerability affecting versions 5.0.11 and earlier of the LatePoint plugin. This vulnerability makes it possible for unauthenticated threat actors to easily take over websites by resetting the password of any user, including administrators. We also detailed an Authentication Bypass vulnerability affecting versions 5.0.12 and earlier of the LatePoint plugin. This vulnerability allows unauthenticated threat actors to gain access to the administrator accounts. These vulnerabilities have been fully addressed in version 5.0.13 of the plugin.

We encourage WordPress users to verify that their sites are updated to the latest patched version of LatePoint.

Wordfence Premium, Wordfence Care, and Wordfence Response users received firewall rules to protect against any exploits targeting these vulnerabilities on September 17, 2024. Sites using the free version of Wordfence will receive the same protection 30 days later on October 17, 2024.

If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.