fb-pixel

Elementor PRO vulnerability: how to solve and avoid damage

Published in:

by:

Warning, there is a vulnerability in Elementor Pro version 3.11.6 or older, which could result in your WordPress site getting hacked. If you use Elementor pro, update now, making sure you have at least version 3.11.7. If you use Elementor free, your website is safe.

Earlier today, an attack took place that exploited this flaw. Our friends at wp-ok notified us right away, and we are letting our customers know accordingly.

TLDR

On March 12, a vulnerability in Elementor Pro was discovered and reported.

The new version 3.11.7 was released by Elementor Ltd on March 22nd, closing this security hole.

Today, a large attack was noticed using this flaw, so it’s time to run for cover.

Solution

The solution to prevent your site from being hacked is updating Elementor Pro as soon as possible.

Since the security hole was fixed with the 3.11.7 version of the plugin, all you have to do is update the plugin to the latest version to sleep peacefully.

Cause of the problem

This vulnerability only affects the Pro version of Elementor. If you use Elementor free, your site is safe and you have nothing to worry about.

When WooCommerce is activated, Elementor loads the file “Elementor-pro/modules/woocommerce/module.php” which adds 2 ajax actions:

/**
 * Register Ajax Actions.
 *
 * Registers ajax action used by the Editor js.
 *
 * @since 3.5.0
 *
 * @param Ajax $ajax
 */
public function register_ajax_actions( Ajax $ajax ) {
   // `woocommerce_update_page_option` is called in the editor save-show-modal.js.
   $ajax->register_ajax_action( 'pro_woocommerce_update_page_option', [ $this, 'update_page_option' ] );
   $ajax->register_ajax_action( 'pro_woocommerce_mock_notices', [ $this, 'woocommerce_mock_notices' ] );
}

The action pro_woocommerce_update_page_option is used by the Elementor editor.

This action calls the function update_option which is used to change the WordPress options in the database:

/**
 * Update Page Option.
 *
 * Ajax action can be used to update any WooCommerce option.
 *
 * @since 3.5.0
 *
 * @param array $data
 */
public function update_page_option( $data ) {
   update_option( $data['option_name'], $data['editor_post_id'] );
}

As you see, this function modifies the option on the database using two values ​​sent by the user.

This feature is for the admin or shop manager to change some WooCommerce settings in the database.

The problem is that there is no check on the data entered by the user, nor is there a check on the role that the user must have to use this function.

Elementor uses its own ajax hadler for most of its ajax calls, so even for pro_woocommerce_update_page_option.

This handler can be found in the file “ Elementor/core/common/modules/ajax/module.php”:

/**
 * Handle ajax request.
 *
 * Verify ajax nonce, and run all the registered actions for this request.
 *
 * Fired by `wp_ajax_elementor_ajax` action.
 *
 * @since 2.0.0
 * @access public
 */
public function handle_ajax_request() {
   if ( ! $this->verify_request_nonce() ) {
      $this->add_response_data( false, esc_html__( 'Token Expired.', 'elementor' ) )
         ->send_error( Exceptions::UNAUTHORIZED );
   }
   [...]

This function checks the nonce to prevent attackers from exploiting a vulnerability.

Elementor free loads all javascript scripts using the hook admin_enqueue_scripts with the file “elementor/core/common/app.php”:

add_action( 'admin_enqueue_scripts', [ $this, 'register_scripts' ] );

So if you use Elementor free, from the browser js console, you can use:

alert( elementorCommon.ajax.getSettings("nonce") );

To see the nonce like this:

Elementor Pro Vulnerability Exposes Nonce

I checked and this is fixed in the latest Elementor version.

An attacker can in this way retrieve the nonce, and make an ajax call, all from the browser console and modify the WordPress settings.

At this point it is only up to the attacker’s creativity to decide what to do.

For example, you can change the setting users_can_register to enable new registrations and set the new role as administrator using the setting admin_email to then register via the WordPress form and be an administrator.

Or you could change the setting siteurl to redirect all traffic to another site.

Alternative solution

As I explained above, the solution is to update Elementor Pro as soon as possible.

In some cases it is possible that the user using WooCommerce and Elementor Pro is unable to update Elementor Pro.

I don’t want in any way to favor those who use Elementor Pro without a license and therefore cannot update directly from the WordPress admin area.

This solution is meant to be a patch for those users who use old versions due to incompatibility between add-ons or other plugins. I do not recommend it, and I would suggest solving the issue as soon as possible in order to keep everything updated correctly.

You can change the Elementor Pro file “Elementor-pro/modules/woocommerce/module.php”.

Look for this part:

/**
 * Update Page Option.
 *
 * Ajax action can be used to update any WooCommerce option.
 *
 * @since 3.5.0
 *
 * @param array $data
 */
public function update_page_option( $data ) {
   update_option( $data['option_name'], $data['editor_post_id'] );
}

And replace with:

	/**
	 * Update Page Option.
	 *
	 * Ajax action can be used to update any WooCommerce option.
	 *
	 * @since 3.5.0
	 *
	 * @param array $data
	 */
	public function update_page_option( $data ) {
		$is_admin = current_user_can( 'manage_options' );
		$is_shop_manager = current_user_can( 'manage_woocommerce' );
		$is_allowed = $is_admin || $is_shop_manager;

		if ( ! $is_allowed ) {
			return new \WP_Error( 401 );
		}

		$allowed_options = [
			'woocommerce_checkout_page_id',
			'woocommerce_cart_page_id',
			'woocommerce_myaccount_page_id',
			'elementor_woocommerce_purchase_summary_page_id',
		];

		$option_name = $data['option_name'];
		$post_id = absint( $data['editor_post_id'] );

		if ( ! in_array( $option_name, $allowed_options, true ) ) {
			return new \WP_Error( 400 );
		}

		update_option( $option_name, $post_id );
	}

It basically does the same thing, but it checks that the user has permissions to modify the options, and allows only some options to be modified.

A note on editing plugins

This is a bad practice, and I will be the first to advise against modifying themes and plugins.

While with themes we have the possibility to create a child theme, this is not possible with plugins.

In this specific case I’m talking about the impossibility of updating Elementor Pro, whatever the reason. In addition, I am applying the same code from version 3.11.7 of Elementor Pro that fixes this vulnerability.

Basically we are modifying the code of a plugin that we cannot update. And if we update it, the new version has the same change, so in fact the problem is minimised.

Non-resolving solutions

There are some solutions on the net, which I do not consider decisive. Let’s see what they are and why they don’t work.

Block the IP range

It was recommended to block the IP range 193.169.194.**

This is a patch that made sense until it was figured out what was going on since the attackers were using that IP range.

Obviously, it doesn’t take that long to change IPs, so it is a measure that protects, but as you can see, it protects within certain limits.

Set the changelog to 404

It was recommended to set the Elementor pro changelog to 404, you can do it with a simple .htaccess directive

RewriteRule /wp-content/plugins/elementor-pro/changelog.txt - [L,R=404]

This is also a solution, although not definitive.

The attack is done in an automated way, so if the bot sees a 404 for this file (which it presumably uses to see what version of Elementor you’re running) it might move on to the next site.

But nothing prevents the bot from checking the resources of the page, just look for something like this:

https://domain.com/wp-content/plugins/elementor-pro/assets/js/nav-menu.bb5cce0a50480cdf695d.bundle.min.js

To understand that the site is using Elementor Pro and try the attack anyway.

Signs of a site under attack

So far, these are the symptoms that have been noticed on attacked sites, if you see any of these things, it is possible that your site has been attacked:

  • The site redirects to another site. It might not be visible because of the cache, so add a random parameter to the url, like domain.it?exsrcdtfvbgy=rdcftvbgy
  • In WordPress settings you see that anyone can register and the default role is not subscriber:
Elementor Pro Vulnerability Check WordPress Settings
  • You’ll see users you don’t recognize. They are most likely administrators.

Example of an attack: server logs

Below is what we found in the server logs after an attempted attack:

/var/log/apache2/domlogs/hidden/hidden.net.hidden.it:193.169.194.63 - - [30/Mar/2023:14:35:05 +0200] "GET / HTTP/1.1" 301 707 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:05 +0200] "GET / HTTP/2" 200 51892 "http://hidden.net" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:06 +0200] "POST //wp-admin/admin-post.php HTTP/2" 200 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:07 +0200] "GET //wp-content/plugins/elementor-pro/changelog.txt HTTP/2" 200 25778 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:08 +0200] "GET / HTTP/2" 200 51892 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:09 +0200] "GET //wp-login.php?action=register HTTP/2" 302 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:10 +0200] "GET /wp-login.php?registration=disabled HTTP/2" 200 2839 "https://hidden.net//wp-login.php?action=register" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:11 +0200] "GET //my-account HTTP/2" 301 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:11 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net//my-account" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:12 +0200] "GET //my-account HTTP/2" 301 20 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:13 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net//my-account" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:14 +0200] "GET /my-account/ HTTP/2" 200 31322 "https://hidden.net/my-account/" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:15 +0200] "POST / HTTP/2" 200 52314 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:35:17 +0200] "POST / HTTP/2" 200 52297 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"
/var/log/apache2/domlogs/hidden/hidden.net.hidden.it-ssl_log:193.169.194.63 - - [30/Mar/2023:14:37:07 +0200] "POST / HTTP/2" 200 51845 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36"

How to check the log

cPanel offers a tool: Raw access log.

Elementor Pro Vulnerability Raw Access Log

From here you see a list of sites on your account, just click on the name of the log to download, you will probably need to download the version that indicates SSL in brackets:

Elementor Pro Vulnerability Download Raw Access Logs

Unzip the file, open it with a text editor and look for the string:

/wp-content/plugins/elementor-pro/changelog.txt

Or IPs starting with:

193.169.194.

Note that the IP address may change, if you notice different IPs being used, please let us know so we can update this article.

Conclusion

Your site is only at risk if you use WooCommerce and Elementor Pro version 3.11.6 or older.

You can fix the vulnerability issue by updating Elementor Pro.

If you can’t update Elementor Pro for whatever reason, you can check the workaround and edit some Elementor Pro files.

Was this article helpful? Do you have any doubts, questions or suggestions for improving this article and preventing other sites from being hacked? Leave a comment and let me know!


Try one of our hosting plans for free and without obligation for 14 days. No payment information required!

Comments

4 responses to “Elementor PRO vulnerability: how to solve and avoid damage”

  1. John Merrymint Avatar
    John Merrymint

    I have elementor pro 3.0.10. Yes I know it’s old, but it seems to not include the vulnerable code, or at least I can’t see any code in the woocommerce module.php file that references “update_page_option”. The code that needs altering, shown in this article, also includes “@since 3.5” in the notes. Could it be that versions earlier than 3.5 are actually unaffected?

    1. If you don’t have that code you don’t have that vulnerability. But with a version that old most likely you have many more. I’d upgrade as soon as possible.

      1. John Merrymint Avatar
        John Merrymint

        Thanks for the reply. As you say, there are some disadvantages to having old code, but you’d be surprised the number of critical issues that have been dodged by actually having older versions of some plugins. It’s counter-intuitive maybe, but I keep a close eye on vulnerabilities (like this one) and update only where necessary, and use multiple methods to keep baddies out. Thanks for this article though, many (including Elementor themselves) don’t offer info on patching the plugin yourself.

      2. I personally prefer to keep everything updated, in these cases patches are released fast, like in this case. And of course I’d try also to limit at maximum the amount of plugins, thus reducing the probability of having a known vulnerability.

Leave a Reply

Your email address will not be published. Required fields are marked *