Elementor PRO vulnerability: how to solve and avoid damage

March 30, 2023 / Published in: Security from Ivan Messina

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.

Table of Contents

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!

Ivan Messina

Founder of SupportHost. With over 10 years of experience in web hosting, he works every day to improve the service and pays attention to each and every customer.

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

John Merrymint says:

May 15, 2023 at 7:56 am

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?

Reply
1. Ivan Messina says:
  
  May 15, 2023 at 1:51 pm
  
  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.
  
  Reply
  1. John Merrymint says:
    
    May 18, 2023 at 8:15 am
    
    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.
    
    Reply
    1. Ivan Messina says:
      
      May 18, 2023 at 1:30 pm
      
      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.
      
      Reply

Cookie	Duration	Description
_dc_gtm_UA-*	1 minute	Google Tag Manager cookie for controlling the loading of a Google Analytics script tag.
_ga	2 years	The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gcl_au	3 months	Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.
_gid	1 day	Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
_GRECAPTCHA	5 months 27 days	This cookie is set by the Google recaptcha service to identify bots to protect the website against malicious spam attacks.
cookielawinfo-checkbox-advertisement	1 year	Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other".
PHPSESSID	session	This cookie is native to PHP applications. The cookie is used to store and identify a users' unique session ID for the purpose of managing user session on the website. The cookie is a session cookies and is deleted when all the browser windows are closed.
promocode	Until the coupon code expires, maximum 1 year	This cookie is set when you visit a page via a link that includes a discount code. The name of the discount code is remembered to remind the user that they can get a discount on the service.
RefID	90 days	This cookie stores the ID of the referral that sent the friend so that if the customer places an order within the next 90 days following the referral, the referral receives a gift for it.
user_currency_pref	11 months	This cookie is set to remember the user's currency.
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
WHMCSAffiliateID	90 days	This cookie stores the ID of the affiliate that made the referral so that if the customer places an order within the next 90 days following the referral, the affiliate receives a commission for it.
WHMCSInstanceID	session	This cookie stores the unique session ID for each visitor and enables variables to pass between page loads. The cookie only contains a reference to a session on the web server. The user's browser won't store any personal information.

Cookie	Duration	Description
_fbp	3 months	This cookie is set by Facebook to display advertisements when either on Facebook or on a digital platform powered by Facebook advertising, after visiting the website.
fr	3 months	Facebook sets this cookie to show relevant advertisements to users by tracking user behaviour across the web, on sites that have Facebook pixel or Facebook social plugin.

Cookie	Duration	Description
cf_chl_*	1 hour	This cookie is used to check whether the Cloudflare Edge server supports cookies.
cf_chl_prog	1 hour	These cookies are used by Cloudflare for the execution of Javascript or Captcha challenges. They are not used for tracking or beyond the scope of the challenge.
cf_chl_rc_ni	1 hour	These cookies are for internal use which allows Cloudflare to identify production issues on clients.
cf_chl_seq_*	session	These cookies are used by Cloudflare for the execution of Javascript or Captcha challenges. They are not used for tracking or beyond the scope of the challenge.
pvc_visits*	1 day	These Cookies are used by Posts View Counter plugin to count visits to specific posts, pages and tutorials.
WHMCSLinkID	364 days	This cookie remembers the link the visitor followed to get to our website, and the system uses it when receiving an order, to be able to associate the conversion with a link to be able to provide stats.

Cookie	Duration	Description
__cf_bm	30 minutes	This cookie, set by Cloudflare, is used to support Cloudflare Bot Management.
__stripe_mid	1 year	This cookie is used to prevent credit card frauds.
__stripe_sid	1 year	This cookie is used to prevent credit card frauds.
WHMCSUser	364 days	This cookie is used for the remember me functionality of the client area. The system only sets it if a client chose to have the system remember their details, ensuring that they don't need to log in multiple times. It is persistent and lasts for 365 days, or until logout.