Rapid Growth in Defacements, Who was Hit, Who is Attacking

Yesterday we published numbers indicating how widespread the defacement campaign is targeting the REST-API vulnerability recently fixed in WordPress 4.7.2. If you have not updated to 4.7.2 already on all sites you operate, do so immediately. If you are using Wordfence Premium, you are already protected.

26% Growth in Defacements in 24 Hours

Yesterday when we published our initial research on the defacement campaigns we are tracking, we published data on 19 separate defacement campaigns. (20 total, but one is the same string, just capitalized differently, so we have removed it.)

This is yesterday’s chart on total defacements per campaign.

The table below shows defacement growth per campaign during the past 24 hours since we published the statistics above. During the past 24 hours we have seen an average growth in defaced pages per campaign of 44%.

The total number of defaced pages for all these campaigns, as indexed by Google has grown from 1,496,020 to 1,893,690. That is a 26% increase in total defaced pages in just 24 hours.

Government, Educational and Commercial Sites All Impacted

This morning we look a look at which websites have been affected by this attack. We only considered the single most successful defacement campaign when doing this research: The “Hacked by MuhmadEmad” campaign.

The following is a partial list of websites that have been defaced by the top defacement campaign alone. So far we have seen:

Vanderbilt University’s Center for Teaching defaced:

Conservative commentator Glen Beck’s site defaced:

ChildCareAware.org, a project funded by the US Department of Health and Human Services defaced:

National American University (Nasdaq: NAUH), a school with over 5,000 students was defaced.

LetsGetHealthy.ca.gov, a California government website was defaced.


The Utah Office of Tourism Industry website defaced:

The US Department of Energy’s Joint Center for Energy Storage Research website defaced:

In the UK we’re seeing local government websites defaced. This is the Offa community council website serving several areas in North Wales.


The list of victims is long and growing. In the UK alone we’re seeing tourism sites, public health websites, support websites, healthcare sites, sites discussing abuse issues and schools all affected by this defacement campaign.

New Campaigns Appearing

In the past 24 hours we have seen 5 new defacement campaigns appear. Their defacement numbers are still low relative to the large numbers we are seeing among established campaigns.

Growth in Unique Attacking IPs

Across all campaigns we are seeing steady growth in the number of unique IP addresses that are attacking WordPress sites using the REST-API defacement attack.


Analyzing the Top Defacement Campaign

When analyzing the top defacement campaign, we looked at other attack methods that “MuhmadEmad” uses. Over the past 90 days the attack types for this threat actor we have detected are:

The above shows which firewall rules in Wordfence blocked this attacker. As you can see this attacker uses a wide range of techniques to deface websites.

Over 95% of attacks that we blocked from “MuhmadEmad” are coming from a single IP address:

IP Address
Total attacks blocked by Wordfence from this IP over 90 days 33,972


Location Montreal, Canada
Hosting provider OVH Hosting, also known as OVH SAS

This attacker uses a range of malware and has switched attack techniques several times during the past 90 days. They recently switched to exploiting websites using the new REST-API vulnerability.


As you can see the defacement campaign targeting the REST-API vulnerability continues with growing momentum. The number of attacking IP addresses has increased and the number of defacement campaigns have increased too. We are also seeing a rapid increase in the number of defaced websites, a 26% increase in total defaced pages in the past 24 hours across the defacement campaigns we started tracking yesterday.

You can help the community by spreading the word as quickly and widely as possible: If you haven’t already updated to WordPress 4.7.2, it is only a matter of time until you are hit by this.

Did you enjoy this post? Share it!


  • Is there any way to keep track of the amount of times a site has been hacked? I've been reading that they will end up defacing each others websites. Curious how that would effect the numbers.

    • An academic will probably tell you, no. But in practice sometimes you can tell based on the type of exploit used or number of defacements or differing motives.

  • Is anything before WP 4.7 immune?

  • Are the IP's where the attacks are originating contacted or is that a waste of time?

    • My guess is the hosting provider is already on top of this and that IP will be offline soon. Run a whois on the IP and drop the abuse email a note if you'd like to contribute.

  • I have been hacked. One of my posts content was changed. I restored an older version of that, and then uptated to 4.7.2. Am I safe now? Could there be any "bad" files left? I've run a wordfence scan (free) and it didn't found anything. So is just updating wordpress enough?

    • An analyst should probably look at your site to make sure. I'd say you're 80% likely to be OK, but you can't be sure.

      Updating WP will fix the vulnerability. No telling if they still have access to anything though.

    • I would like to suggest to at the very least change each and every password for the site. That is WP login as well as cPanel login, database, FTP and emails (if applicable).

    • It totally depends on the attack type., If it was a simple defacement than you will be fine by now., but if the hacker has left any back link or back gate in your website, then it is only a matter of sec they can hack you again... Check your 404.php files of webpage and also also every 404.php in your theme files in your cpanel account.. If it is clear than its alright.. You can also scan your website for defacement attacks or any other malware online.

  • All of the website that were affected that I personally had to deal with were already on WordPress version 4.7.2. I am not sure how effective updating to 4.7.2 will be... is there any data to show 4.7.2 hasn't experienced hacks from these campaigns?

    • Yes. We haven't seen a single one. Neither has any other security company that I'm aware of. 4.7.2 is not vulnerable to this hack.

  • It's nice to show all the numbers of defacements and what not and it's nice that it will probably generate some extra business for Wordfence, but what is worse and what nobody seems to care about is that literally millions of sites that are hacked still won't move Core dev to simply disable REST API by default.

    The ticket opened on the topic (https://core.trac.wordpress.org/ticket/39806#ticket) is already dead in the water and news on the topic on sites that don't have a commercial interest in the outcome make it sound that it's only a few sites that have suffered (https://wptavern.com/wordpress-rest-api-vulnerability-is-being-actively-exploited-hundreds-of-thousands-of-sites-defaced): hundreds of thousands vs literally millions.

    The REST API is only for perhaps 1% (or less) of developers and is definitely not ready for mainstream and always-on.

    The way things are going - and have been going for a while already - forces people in the direction to develop sites locally, compile them and publish a fully static site. Or move to Wix or Squarespace and the likes where this kind of crap simply doesn't happen.

  • Makes me wonder if the main objective of these type of hacks just defacing the site? Like graffiti tagging on a wall?

    Seems other hackers break-in quietly so the website owner doesn't even know so they can use their computers to spam, etc. but these dirtbags seem to be seeking attention. Odd.

    • @Alan: It's likely that this is all they could do given the nature of the REST-API attack, so that's why they advertised their presence. It's very much like graffiti tagging a wall.

  • Ken, in an earlier comment, asks whether anything PRIOR to WP 4.7 is vulnerable to this REST-API attack? I would like to see an answer to that. Also, are versions of WP older than 4.5 (when REST-API was added to the core) affected by this, assuming the site was not using the REST-API plugin?

    Yes, I know there are other vulnerabilities in older releases, but for purposes of this vulnerability only, I'd like to know the answers.

    • Only 4.7 and 4.7.1 were affected. 4.6.X and below are not affected because they don't include the REST API functionality which was released with the 4.7 update.

  • I'm waiting for an apology from the Wordpress developers who caused this. Or are they working on the next great thing for the hackers?

    • If you regularly send them thank-yous for the awesome product and back-end services they provide, then I think it's reasonable for you to expect an apology in return when they write the occasional bug. WordPress is totally free. Not only that, it's free for you to modify in any way you want and use in your own products, provided those products are also made free based on the same license terms.

      Come on guys. No witch hunting. A vulnerability is just a bug. Developers write bugs all the time. If I had a dollar for every bug I've written....

      You can't innovate and not introduce the risk of writing bugs. The goal with REST-API is to innovate and turn WordPress into more of an operating system or platform for publishing rather than just a simple web application with web based user-interface. It's a big hairy audacious goal and I think it's admirable that a product and open source team with such a large user base and so many dependencies is still able to innovate in the way that they are.

      Good for them! We should all be cheering them on. And if they write the occasional bug that sneaks through testing and gets into production, we've got their backs with Wordfence's firewall and malware detection.


      • Innovation is great, Mark. But the only sites who should have had this feature enabled by default are those who had the REST API plugin installed and activated. The decision to enable it for everyone by default was a boneheaded one and there were good reasons upfront to disable by default and let the site owner enable if they wanted it.

        With WordPress auto-upgrade in effect and site owners sometimes not knowing about new features for a while, having a security mindset in effect - which would have dictated this feature be disabled by default - would have mitigated this problem.

        • Thanks Ren. Interesting point of view.

      • Mark, Your comment is exactly correct. WP is used by many millions of users. It is great software, overall, and is constantly changed and updated to make it safer, easier to use, and have better features.
        Having a 20+ year history of programming and systems analysis for some of the largest Aerospace and defense contractors in the US, I know that bugs happen. None of us are perfect, nor can we spend the time or have the capability to try to think up every possible way a hacker may try to break in. We all do our best, read as much as we can to learn more, and then deal with it when some bozo who has NO LIFE spends a massive amount of time breaking into other sites.

        My site was hacked twice in 2015. Luckily both were "defacements". I spent considerable time hardening our site security and have been successful at keeping hackers out. . . . so far. I believe no site is absolutely safe from individuals who spend their life just causing others difficulty. (What a waste of brain power.)

        Thank you for standing up for a great team of developers at WP who really do their very best at creating a better and better product.

        Stuff happens.

  • Great article. We were wondering how those defacements were being done. We initially figured a phishing attack on a user but, with the muhmademad hack, the WordPress revisions (on the admin editing page) looked suspicious -- no avatar, etc. There was also no log entry of any user (at all) on the day of the attack. One more curious note - I could find no revision entry in the wp_posts table for this revision (altho I could be remembering this from looking after our clean-up.) All of this had led us to believe that it was probably not someone logging in through the admin interface.

    FYI - we installed the Premium WordFence version after this :)