90,000 WordPress Sites Affected by Arbitrary File Upload and Authentication Bypass Vulnerabilities in Jupiter X Core WordPress Plugin

📢 Did you know Wordfence runs a Bug Bounty Program for all WordPress plugins and themes at no cost to vendors? Through October 7th, 2024, XSS vulnerabilities in all plugins and themes with >=1,000 Active Installs are in scope for all researchers. In addition, through October 14th, 2024, researchers can earn up to $31,200, for all in-scope vulnerabilities submitted to our Bug Bounty Program! Find a vulnerability, submit the details directly to us, and we handle all the rest.

On August 6th, 2024, we received a submission for an Arbitrary File Upload vulnerability in Jupiter X Core, a WordPress plugin with more than 90,000 active installations. This vulnerability makes it possible for an unauthenticated attacker to upload arbitrary files to a vulnerable site and achieve remote code execution, which is typically leveraged for a complete site takeover.

On the same day, we also received a submission for a Limited Authentication Bypass to Account Takeover vulnerability in the same plugin. This vulnerability makes it possible for unauthenticated attackers to log in as the first user who logged in using Google or Facebook, including administrator accounts.

Props to Geo Void who discovered and responsibly reported these vulnerabilities through the Wordfence Bug Bounty Program. This researcher earned a bounty of $2,145.00 for the Arbitrary File Upload and $1,690.00 for the Authentication Bypass to Account Takeover discoveries. Our mission is to Secure the Web, which is why we are investing in quality vulnerability research and collaborating with researchers of this caliber through our Bug Bounty Program. We are committed to making the WordPress ecosystem more secure, which ultimately makes the entire web more secure.

All Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those using the free version of our plugin, are protected against any exploits targeting the Arbitrary File Upload vulnerability by the Wordfence firewall’s built-in Malicious File Upload protection.

Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against any exploits targeting the Authentication Bypass to Account Takeover vulnerability on August 14, 2024. Sites using the free version of Wordfence received the same protection 30 days later on September 13, 2024.

We contacted the Artbees team on August 14, 2024, and received a response on August 20, 2024. After providing full disclosure details, the developer released the first patch on August 22, 2024, the second patch on September 12, 2024, and the third patch on September 18, 2024. We would like to commend the Artbees team for their prompt response and timely patch.

We urge users to update their sites with the latest patched version of Jupiter X Core, which is version 4.7.8, as soon as possible.

Vulnerability Summary from Wordfence Intelligence

The Jupiter X Core plugin for WordPress is vulnerable to arbitrary file uploads due to a mishandled file type validation in the ‘validate’ function in all versions up to, and including, 4.6.5. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site’s server which may make remote code execution possible.

The Jupiter X Core plugin for WordPress is vulnerable to authentication bypass in all versions up to, and including, 4.7.5. This is due to improper authentication via the Social Login widget. This makes it possible for unauthenticated attackers to log in as the first user to have logged in with a social media account, including administrator accounts. Attackers can exploit the vulnerability even if the Social Login element has been disabled, as long as it was previously enabled and used. The vulnerability was partially patched in version 4.7.5, and fully patched in version 4.7.8.

Technical Analysis #1: Unauthenticated Arbitrary File Upload

Jupiter X Core is a WordPress plugin that provides the core functionality for the Jupiter X premium theme.

Examining the code reveals that the plugin uses the handle_frontend() function in the Ajax_Handler class to handle the form submission. The validate_fields() function in the same class is used to validate the form fields.

private function validate_fields() {
	$form_fields = $this->form['settings']['fields'];

	foreach ( $form_fields as $field ) {
		if (
			( isset( $field['_enable'] ) && 'false' === $field['_enable'] ) &&
			empty( $field['enable'] )
		) {
			continue;
		}

		$field['type'] = empty( $field['type'] ) ? 'text' : $field['type'];
		$class_name    = 'JupiterX_Core\Raven\Modules\Forms\Fields\\' . ucfirst( $field['type'] );

		$class_name::validate_required( $this, $field );
		$class_name::validate( $this, $field );
	}

	if ( ! empty( $this->response['errors'] ) ) {
		$this->send_response();
	}

	return $this;
}

The $this->form['settings'] and its fields depend on the settings in Elementor. The fields array content might look like this, for example:

[
{"label":"Name","_id":"7392602","type":"text","required":"",...},
{"label":"Email","_id":"f27c46d","type":"email","required":"true",...},
{"label":"Message","_id":"6a389bd","type":"textarea","required":"",...},
{"label":"File","_id":"475fb85","type":"file","required":"",...}
]

The function, depending on the type, for example in the case of a file form field, invokes the validate_required() and the validate() functions from the JupiterX_Core\Raven\Modules\Forms\Fields\File class.

The validate_required() function invokes the fix_file_indices() function, which changes the original $_FILES structure to a new one.

The validate() function includes a completely common file type validation that checks the file extension.

After the validation functions, the upload_files() function is called in the Ajax_Handler class.

public function upload_files() {
	// phpcs:ignore WordPress.Security.ValidatedSanitizedInput
	$fields = isset( $_FILES['fields'] ) ? $_FILES['fields'] : false;

	if ( ! $fields ) {
		return $this;
	}

	$valid_fields = [];

	foreach ( $this->form['settings']['fields'] as $form_fields ) {
		$valid_fields[ $form_fields['_id'] ] = $form_fields['type'];
	}

	foreach ( $fields as $id => $field ) {

This function validates that only the files specified in the form settings will be uploaded.

Unfortunately, the $valid_fields array contains all the fields configured for the current form, not only the file type fields, as it is not restricted by type in the vulnerable version. This means it is possible to bypass the file validation by simply sending a file with the id of another expected text or textarea field, and since these field types do not implement the validate_required() and validate() functions, there are no restrictions on their value.

This means that any file can be uploaded without validation or restrictions, including malicious .php files. The file is uploaded to the WordPress uploads folder, which is publicly accessible. The filename is generated using the uniqid() function and the original file extension. This makes it possible for unauthenticated attackers to upload arbitrary malicious PHP code and then access the file to trigger remote code execution on the server.

As with all arbitrary file upload vulnerabilities, this can lead to complete site compromise through the use of webshells and other techniques.

Technical Analysis #2: Limited Unauthenticated Authentication Bypass to Account Takeover

This technical analysis details the Google social login in depth, but the vulnerability is also present in the Facebook social login, with different parameters and values.

Examining the code reveals that the plugin, in the ajax_handler() function in the JupiterX_Core\Raven\Modules\Forms\Classes\Social_Login_Handler\Google class, sends a request to Google’s OAuth tokeninfo endpoint with the ‘id_token‘ parameter.

$token    = filter_input( INPUT_POST, 'token', FILTER_SANITIZE_STRING );
$url      = 'https://oauth2.googleapis.com/tokeninfo?id_token=' . $token;
$response = wp_remote_get( $url );

if ( ! is_array( $response ) || is_wp_error( $response ) ) {
    wp_send_json_error( __( 'Google API Error', 'jupiterx-core' ) );
}

$body        = $response['body'];
$information = json_decode( $body, true );

Then, it stores the response in the $information variable.

$user_google_id   = $information['sub'];

$set_meta         = $this->set_user_google_id( $user_id, $user_google_id );

After that, the ‘sub‘ value, which stands for ‘subject’ and is a unique identifier associated with a user in Google OAuth, is stored in the WordPress user’s user meta.

private function set_user_google_id( $user_id, $user_google_id ) {
    update_user_meta( $user_id, 'social-media-user-google-id', $user_google_id );
}

Further examination of the code that follows, reveals that it works completely differently from the usual OAuth authentication. This is because it uses the ‘sub‘ value to generate a unique login link with the create_unique_link_to_login_google_user() function.

$unique_login_url = $this->create_unique_link_to_login_google_user( $user_google_id );

private function create_unique_link_to_login_google_user( $user_google_id ) {
    $site      = site_url();
    $login_url = $site . '?jupiterx-google-social-login=' . $user_google_id;

    return $login_url;
}

The created login link is handled by the google_log_user_in() function, which is assigned to the init hook, making it accessible to everyone.

The most significant problem and vulnerability is caused by the fact that this is accessible via a completely separate link, while the OAuth standard does not require a separate identifier to be created and accessible through a link, which could potentially be exposed to attackers. It is sufficient to identify and log in the user based on the email or identifier received in the response from Google.

public function __construct() {
    add_action( 'init', [ $this, 'google_log_user_in' ] );
}

public function google_log_user_in() {
    if ( ! isset( $_GET['jupiterx-google-social-login'] ) ) { // phpcs:ignore
        return;
    }

    $value = filter_input( INPUT_GET, 'jupiterx-google-social-login', FILTER_SANITIZE_STRING );
    $user  = get_users(
        [
            'meta_key'    => 'social-media-user-google-id', // phpcs:ignore
            'meta_value'  => $value, // phpcs:ignore
            'number'      => 1,
            'count_total' => false,
        ]
    );
    $id    = $user[0]->ID;

    wp_clear_auth_cookie();
    wp_set_current_user( $id ); // Set the current user detail
    wp_set_auth_cookie( $id ); // Set auth details in cookie

Unfortunately, the function does not include an empty value check for the ‘jupiterx-google-social-login‘ parameter. This means that if an empty value is provided, the get_users() function returns the first user with the ‘social-media-user-google-id‘ user meta, in other words, the user who first used the social login.

An attacker with the first attack method is limited to what users they can log in as due to the fact that it is only possible to log in as the first user who signed in on a vulnerable site using Google or Facebook. In most cases however, the administrator is the first user, and it is common for them to set up and use social login, either for testing purposes or because it is a convenient feature. In these cases, there is a chance that by exploiting the authentication bypass vulnerability, an attacker can gain access to an administrative user account or another higher-level user account.

To exploit the second attack method, the attacker needs to obtain the victim’s social identifier. In the case of Google, this is the ‘sub‘ value, and for Facebook, it’s the ‘user_id‘ value. This attack is much more complex and requires user interaction, as the attacker must trick the victim into clicking a link and using the attacker’s crafted social login to obtain the victim’s identifier.

Disclosure Timeline

August 6, 2024 – We received the submission of the Arbitrary File Upload vulnerability in Jupiter X Core via the Wordfence Bug Bounty Program.
August 6, 2024 – We received the submission of the Authentication Bypass to Account Takeover vulnerability in Jupiter X Core via the Wordfence Bug Bounty Program.
August 8, 2024 – We validated the reports and confirmed the proof-of-concept exploits.
August 14, 2024 – Wordfence Premium, Care, and Response users received a firewall rule to provide protection against any exploits that may target the Authentication Bypass to Account Takeover vulnerability.
August 14, 2024 – We initiated contact via the vendor contact form, asking that they confirm the inbox for handling the discussion.
August 20, 2024 – After not receiving a response, we followed up by sending an email to the vendor.
August 20, 2024 – The vendor confirmed the inbox for handling the discussion.
August 20, 2024 – We sent over the full disclosure details to the vendor. The vendor acknowledged the report and began working on a fix.
August 22, 2024 – The partially patched version of the plugin, 4.6.6, is released.
September 12, 2024 – The partially patched version of the plugin, 4.7.5, is released.
September 13, 2024 – Wordfence Free users received the same protection against the Authentication Bypass to Account Takeover vulnerability.
September 18, 2024 – The fully patched version of the plugin, 4.7.8, is released.

Conclusion

In this blog post, we detailed an Arbitrary File Upload vulnerability affecting versions 4.6.5 and earlier of the Jupiter X Core plugin. This vulnerability makes it possible for an unauthenticated attacker to execute malicious code on the server. We also detailed a Authentication Bypass to Account Takeover vulnerability affecting versions 4.7.5 and earlier of the Jupiter X Core plugin. This vulnerability allows unauthenticated threat actors to gain access to the first user who used social login. These vulnerabilities have been fully addressed in version 4.7.8 of the plugin.

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

Wordfence Premium, Wordfence Care, and Wordfence Response users received a firewall rule to protect against any exploits targeting the Authentication Bypass to Account Takeover vulnerability on August 14, 2024. Sites using the free version of Wordfence received the same protection 30 days later on September 13, 2024.

All Wordfence Premium, Wordfence Care, and Wordfence Response customers, as well as those using the free version of our plugin, are protected against any exploits targeting the Arbitrary File Upload vulnerability by the Wordfence firewall’s protection.

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 these vulnerabilities pose a significant risk.