Featured image - Header text on background of padlock images on a screen

Malicious Attack Campaign Targeting Jetpack Users Reusing Passwords

The Wordfence Threat Intelligence and Site Cleaning teams have been tracking a malware campaign that redirects all site visitors to malvertising domains, while attempting to keep site administrators unaware of the infection. Since June 1, 2021, the number of sites we are tracking that have been infected with this malware has more than doubled, and we expect this campaign to continue gaining momentum as it relies on a mechanism that is difficult to block directly.

Jetpack is one of the most popular plugins in the WordPress repository, and it has a dizzying array of features that require users to connect their sites to a WordPress.com account. One of these features allows users that are logged in to WordPress.com to perform administrative tasks, including plugin installation, on sites that are connected to WordPress.com via Jetpack.

Unfortunately this means that if the credentials for a WordPress.com account are compromised, an attacker can login to that WordPress.com account and install arbitrary plugins on the connected WordPress site no matter where it is hosted. This includes the malicious plugin used in this campaign. We’ve written about this intrusion vector in the past, and it is regaining popularity due to a number of recent data breaches from other services.

To clarify, no data breach has occurred at WordPress.com itself. However, password reuse is incredibly common, and credentials obtained from recent data breaches are likely to grant access to a number of WordPress.com user accounts. Additionally, although it is possible to configure Jetpack to allow direct login to a site via WordPress.com credentials, this setting does not need to be enabled in order for a site to be vulnerable. All that is required is that a site be connected to a WordPress.com account that has compromised credentials.

What should I do?

If you use Jetpack, you should turn on 2-Factor authentication at WordPress.com. While we strongly recommend using a mobile app or security key for this, even SMS-based 2-Factor authentication is significantly more secure than relying on passwords alone.

If you use the same password for your WordPress.com account that you’ve used for any other service, change your WordPress.com password immediately.

If your site has been compromised, we’ve published a guide that is useful to help you clean your WordPress site with Wordfence. Restoring from a recent backup can definitely be an option if you can identify the last known clean backup. Reviewing your log files can help.

If you’d like support in restoring your site to functionality, our Site Cleaning team can help. All Wordfence site cleaning customers receive a Wordfence Premium license key to protect the site going forward as well as a one-year guarantee. If the site is compromised again after recommendations are followed, we’ll clean it again for free.

Indicators of Compromise

The majority of infections we’ve seen have the following plugin and filenames:


The most common MD5 hashes associated with this campaign are:


These malicious plugins check to see if the site visitor is on the login page, or if they are logged in as an administrator. Any visitor that doesn’t meet these criteria will then be redirected to one of several dozen malicious punycode domains.

We have listed the domains associated with the most prevalent variant:



In today’s article, we covered a malware campaign targeting sites connected to WordPress.com via the JetPack plugin. As this campaign depends on compromised WordPress.com credentials, it is not possible to block this type of attack directly, but that doesn’t mean there’s nothing you can do.

At this time we recommend that all site owners using the Jetpack plugin enable 2-factor authentication for their WordPress.com accounts, and change their WordPress.com passwords if they are using a password that has been used for any other service. If you do not actively use Jetpack, you should disconnect your site from WordPress.com or deactivate the Jetpack plugin.

Special thanks to Security Analyst Charles Sweethill for tracking this issue and assisting with the article.
This article was written by Ramuel Gall, a former Wordfence Senior Security Researcher.

Did you enjoy this post? Share it!


  • I had this on a number of sites so I wrote this code to protect the site and put it in functions.php the problem we had is that the plugin kept reappearing if you deleted it. Now we know its jetpack it's been secured thanks Word Fence

    Meanwhile - this in functions.php of the theme stops the files remaining there even if they manage to put them back.

    * To be inserted into functions .php
    * Deletes builder and plug viruses
    function delete_directory($dirname) {
    if (is_dir($dirname))
    $dir_handle = opendir($dirname);
    if (!$dir_handle)
    return false;
    while ($file = readdir($dir_handle)) {
    if ($file != "." && $file != "..") {
    if (!is_dir($dirname . "/" . $file))
    unlink($dirname . "/" . $file);
    delete_directory($dirname . '/' . $file);
    return true;
    delete_directory(WP_PLUGIN_DIR . '/Builder');
    delete_directory(WP_PLUGIN_DIR . '/plugs');
    delete_directory(WP_PLUGIN_DIR . '/Plugin');

  • Additionally: https://jeffowens.realtor/

    Just a follow up. I just recently added jet-pack to two site. Self Hosted. The advisory reads as wordpress.com sites, does the same guidance include self hosted sites?

    • Hi Jeff,

      This issue impacts self-hosted sites only. However, the Jetpack plugin requires that you connect your self-hosted site to WordPress.com to use much of its functionality. It is these self-hosted sites that are connected to a WordPress.com account that has had compromised credentials that are being infected.

  • A previous administrator installed Jetpack but I have that plugin disabled. However, we also use Askimet which is connected back to WordPress.com. Does that mean we are still vulnerable? Also If the previous admin still has a WordPress.com account but no longer has a WordPress account on our system is that a problem and would that make us vulnerable it their account is compromised even though they no longer have a local WordPress account on our system?

    • Hi Mike,

      If Jetpack is disabled you should be safe - it is only sites running a Jetpack installation that is actively connected to a WordPress.com account that has had compromised credentials that are seeing issues. We are not aware of any issues with Akismet that could be used to infect a site via a compromised WordPress.com account.

    • Ram is correct that having Akismet installed and connected does not make you vulnerable to this attack.

  • Thank you for the amazing work you do. We had this happen to a site this week and we were completely perplexed how the malicious plugin kept getting installed (after being deleted multiple times). It was 100% a jetpack issue.

    Keep up the good work!

  • A week ago I had (quickly) cleaned a site with this hack as well and when it came back the next day, I examined the access log and noticed POST statements related to Jetpack on the timestamp when the malicious plugins were installed. Jetpack wasn't actually used on the site (it was installed because WooCommerce recommended it with annoying notifications), so we removed it. And I told the client he should change his passwords for both his own site as for wordpress.com and for other platforms he used these credentials for.

    So thank you for the research and the publication of this article! I've shared it with my client. :-)

  • I had this infection on a client's website, I understood by looking at the logs that showed requests from Jetpack.

    I had found information on similar malware in an old article:

    (My client used an email address that was 20 years old and still used the same password.
    His email addresses appeared in hacked email databases.)

    Thank you ;-)

  • Thank you for this information and for the tip about enabling 2FA.