Switching From WordPress to ClassicPress

With what is going on with WordPress, there has been a lot of discussion of there being a fork of WordPress. It’s a bit odd as there has already been a fork of WordPress that has been around for years. It’s ClassicPress. It does have a big difference as it doesn’t support the block (Gutenberg) editor. But for anyone that doesn’t need that, it is available and isn’t a flash in the pan.

ClassicPress refers to switching from WordPress to ClassicPress as a migration in their documentation. For those that have dealt with migration between versions of some CMSs that might sound scary, as the migration involves largely starting over. That isn’t the case with ClassicPress.

The basics of the migration process are really simple, though depending on your setup, it might require more extensive work.

The first step is to install the Switch to ClassicPress plugin in the existing WordPress website.

Once that is activated, the Tools menu in the backend of WordPress will now have a Switch to ClassicPress item.

If there is nothing the plugin detects that would stop the migration, you will see a screen like this:

It has a couple of warnings about possible incompatibilities, but nothing blocking the migration.

If you are unlucky, there may be a blocking issue that stops the migration from being possible until it is addressed:

Going back to what is shown in the first image, the only remaining step is click to the button to do the migration.

If everything goes right, as it did with the website shown in the screenshots. After clicking the button, the website was seamlessly switched to ClassicPress.

Before making any change like this, it would be a very good idea to make a full backup. You already should be making backups for the website.

Even better would be to do a test run of the migration first on a copy of the website. That way you can make sure that your theme and plugins are fully compatile with ClassicPress. If there are issues, it is easier to address them when not having to address on your production website. Or worst case scenario, you realize that your set up isn’t compatible with ClassicPress in the way that can reasonably be fixed, before you switch the production website.

For those looking to have someone else handle the migration for them, and address any problems that crop up, we can do a WordPress to ClassicPress migration for you.

You Don’t Need a Plugin To Have WordPress Send Email Through SMTP

If you want to improve the security of your WordPress website, removing unneeded plugins is a good idea. Every additional plugin you have is more code that could be insecure. One place that a lot of websites could do that is with their usage of a plugin to have email sent through SMTP instead of directly through the server the website is hosted on. There are millions of websites using plugins to do that. That includes hundreds of thousands using a plugin that is known to be vulnerable. Many of those websites could replace the plugin being used with a few lines of code added to the WordPress configuration file. That file is named wp-config.php and is usually in the root directory of the website (it could also be in the directory above that).

The lines to add to the file are as follows:

define( ‘SMTP_username’, ” );
define( ‘SMTP_password’, ” );
define( ‘SMTP_server’, ” );
define( ‘SMTP_PORT’, ” );
define( ‘SMTP_SECURE’, ‘tls’ );

You need to fill in the details for username and other credentials on the lines that have a ” in them. If you already have a plugin set up to handle that, you simply need to copy those values. Otherwise, the email provider should list those details for the email account.

Your WordPress Web Host Might Not Really Your Web Host

The current situation with WordPress has exposed a lot of things about WordPress that have largely been hidden away. The lawsuit filed by WP Engine against the company closely associated with WordPress and its CEO focused a lot on that. Seemingly unrelated to that, it also quoted someone that made quite an admission. They claim to host websites, but as they then admit just a sentence later, they are not really hosting websites:

We are in the same boat. We host websites for schools, nonprofits and mostly rural police and fire departments. We have been working with WP engine for seven years and our margins are not big enough to afford to hire in all of the technical services that WP engine provides as part of its hosting package.

Another way to put that is that they are charging their customers a premium for web hosting that they could otherwise buy themselves for less. That could be worth it, if they are providing some value beyond what you could get with going with the same web host directly. But it also could just mean higher costs. Unnecessary higher costs for schools, nonprofits and mostly rural police and fire departments isn’t a good thing.

If you are looking to get away from someone who is up charging you for web hosting, we can handle moving your WordPress website to a new web host.

WP Engine Isn’t Hacking WordPress, It Is Using Functionality That WordPress Provides as Intended

Right now the head of WordPress, Matt Mullenweg, is doing a lot of damage to everyone else that is involved in WordPress. The direct cause of this is that he is trying to extort a competitor of his for-profit company Automattic. One of his tactics that has been successful in tricking some people that are not familiar with how WordPress works, is claiming the competitor is hacking WordPress to do things it shouldn’t do.

In one post on WordPress’ website, he described that hacking this way:

What WP Engine gives you is not WordPress, it’s something that they’ve chopped up, hacked, butchered to look like WordPress, but actually they’re giving you a cheap knock-off and charging you more for it.

In a follow up post, he put it this way:

WP Engine is free to offer their hacked up, bastardized simulacra of WordPress’s GPL code to their customers, and they can experience WordPress as WP Engine envisions it, with them getting all of the profits and providing all of the services.

But if you look the two supposed hacks, it turns out that WordPress is actually intended to do be able to do those things. So WP Engine isn’t hacking anything at all.

Revisions

The first “hack” involves limiting or disabling post revisions. Here is how he described that:

WordPress is a content management system, and the content is sacred. Every change you make to every page, every post, is tracked in a revision system, just like the Wikipedia. This means if you make a mistake, you can always undo it. It also means if you’re trying to figure out why something is on a page, you can see precisely the history and edits that led to it. These revisions are stored in our database.

This is very important, it’s at the core of the user promise of protecting your data, and it’s why WordPress is architected and designed to never lose anything.

WP Engine turns this off.

If you were to do a search to see how to disable revisions yourself, one page you might then go to is a page on the website’s for one Automattic’s businesses, which provides this explanation on how to do this, which starts this way:

Although revisions are enabled by default in WordPress, you can easily disable them by taking similar steps to the ones discussed above. To disable WordPress post revisions, you’ll need to modify the wp-config.php file.

You can find instructions on accessing the file in the previous section, where we cover how to limit WordPress revisions. Once you find the file, you’ll need to edit the WP_POST_REVISIONS code to disable them entirely. This is the new line you’ll use:

define( 'WP_POST_REVISIONS', false );

So adding a single line of code to a file allows this, despite his claim that WordPress is “architected and designed to never lose anything.”

It goes on to link to a plugin that is available in WordPress’ own plugin directory to do the same.

Information on disabling revisions can also be found in WordPress’ own documentation.

News Feed

The second “hack” was described this way by him:

I won’t bore you with the story of how WP Engine broke thousands of customer sites yesterday in their haphazard attempt to block our attempts to inform the wider WordPress community regarding their disabling and locking down a WordPress core feature in order to extract profit.

The story he didn’t want to bore people with is that he heard a rumor that a news feed was being removed by WP Engine:

Heard a rumor @wpengine is trying to remove the news feed from wp-admin dashboards so people don’t see my post about them, can anyone confirm or deny?

If you are confused about how that relates to what he claimed about WP Engine, you are not alone. What he said doesn’t make sense.

What actually happened is that WP Engine stopped showing links to pages being used by Matt Mullenweg as part of his extortion campaign. This doesn’t break websites and is something that, again, WordPress allows.

One way to do that is to use a WordPress plugin. That is available plugin that is available in WordPress’ own plugin directory and, if you pay for a higher tier of Matt Mullenweg’s competing hosting service to WP Engine, available as well. The plugin uses WordPress hooks, which are there to do things just like this.

What You Can Do About This

The concern that a lot of people have about the whole situation is very real. Just the fact that the head of WordPress is making those unhinged claims about a “hack” that are easily checked to be false is alarming. This situation is likely to be headed to civil legal action and possibly criminal legal action, which won’t involve those using WordPress. But what can you do?

In the short term, making sure that Matt Mullenweg’s misinformation about WP Engine is countered is important. We have no connection to WP Engine, but they are clearly a victim, even if they have their own problems.

In the longer term, unless things change, you can consider moving away from solutions from Automattic and maybe even WordPress. We don’t like saying that, but what is happening is really bad.

If you use WordPress and don’t use its the Gutenberg (block) editor, you can switch over to an existing fork of WordPress, ClassicPress. Which has been available since 2019 and, unlike, WordPress has governance. We can help with that.

What Hacker Does When They Try to Regain Access to a Hacked WordPress Website Through a Backdoor

A couple of months ago, we talked about the difference between a website that is repeatedly hacked due to an unaddressed vulnerability and a backdoor. How you handle those situations is also different and you need to figure out which has occurred to handle it right. One way to help figure out which is occurring is to review the log files of requests to the website, after the website has been cleaned up, to see what the hacker then does. We did just that with a hacked WordPress website we were cleaning up that had an issue with backdoors.

The first requests the hacker made were to try to access malicious code that the hacker added that runs when accessing the website:

  • 157.90.177.207 – – [03/Apr/2024:18:34:46 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36 Edg/115.0.1901.183”
  • 164.92.131.172 – – [03/Apr/2024:18:34:47 -0700] “POST /index.php?AyGb=Bcsmp HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”

After that failed because the website had been cleaned, they then made requests to many backdoor files they had previously placed on the website to try to regain access and add malicious code back on the website:

  • 162.241.253.213 – – [03/Apr/2024:18:34:49 -0700] “POST /profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5.2 Safari/605.1.15”
  • 198.57.247.231 – – [03/Apr/2024:18:34:50 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 103.93.160.210 – – [03/Apr/2024:18:34:51 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 15_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/110.0.5481.83 Mobile/15E148 Safari/604.1”
  • 64.202.190.47 – – [03/Apr/2024:18:34:54 -0700] “POST /.wp-cli/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
  • 192.185.4.62 – – [03/Apr/2024:18:34:56 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; RMX2103) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 185.26.106.164 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 13; SM-A715F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 162.241.230.71 – – [03/Apr/2024:18:34:57 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6,2 Safari/605.1.15”
  • 161.35.61.218 – – [03/Apr/2024:18:34:58 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; vivo 1915) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Mobile Safari/537.36”
  • 217.117.128.10 – – [03/Apr/2024:18:35:00 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_0_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.0 Mobile/15E148 Safari/604.1”
  • 50.62.150.220 – – [03/Apr/2024:18:35:02 -0700] “POST /cgi-bin/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 132.148.120.153 – – [03/Apr/2024:18:35:03 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36”
  • 198.57.247.226 – – [03/Apr/2024:18:35:04 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
  • 182.50.132.94 – – [03/Apr/2024:18:35:05 -0700] “POST /[redacted]/wp-content/uploads/2022/profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; M2010J19SG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Mobile Safari/537.36”
  • 69.163.178.127 – – [03/Apr/2024:18:35:07 -0700] “POST /[redacted]/wp-includes/block-supports/quxgekpc.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; M2004J19C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.101 Mobile Safari/537.36”
  • 69.49.241.41 – – [03/Apr/2024:18:35:08 -0700] “POST /[redacted]/wp-includes/block-supports/mptrluah.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; arm_64; Android 11; 21091116UG) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 YaBrowser/23.1.4.84.00 SA/3 Mobile Safari/537.36”
  • 157.230.240.43 – – [03/Apr/2024:18:35:10 -0700] “POST /.wp-cli/wp-login.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
  • 95.216.8.84 – – [03/Apr/2024:18:35:11 -0700] “POST /[redacted]/wp-includes/PHPMailer/admin.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 6.0; ALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.74 Mobile Safari/537.36”
  • 63.228.175.170 – – [03/Apr/2024:18:35:12 -0700] “POST /profile.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1”
  • 50.87.144.121 – – [03/Apr/2024:18:35:13 -0700] “POST /[redacted]/wp-includes/images/admin-ajax.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_1_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Mobile/15E148 Safari/604.1”
  • 92.222.10.62 – – [03/Apr/2024:18:35:15 -0700] “POST /[redacted]/wp-includes/theme-compat/ldgjoguq.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Safari/605.1.15”
  • 103.74.116.113 – – [03/Apr/2024:18:35:21 -0700] “POST /[redacted]/wp-admin/css/fkeyshcu.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; CMA-LX2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.98 Mobile Safari/537.36”
  • 202.28.78.37 – – [03/Apr/2024:18:35:23 -0700] “POST /[redacted]/wp-includes/js/imgareaselect/options.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 169.45.200.230 – – [03/Apr/2024:18:35:25 -0700] “POST /wp-content/plugins/olympus-google-fonts/includes/customizer/controls/js.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.2 Mobile/15E148 Safari/604.1”
  • 50.62.176.231 – – [03/Apr/2024:18:35:26 -0700] “POST /cgi-bin/wp-login.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) GSA/273.0.547966426 Mobile/15E148 Safari/604.1”
  • 109.105.49.240 – – [03/Apr/2024:18:35:27 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 157.90.145.251 – – [03/Apr/2024:18:35:28 -0700] “POST /index.php?vfb=Klkw HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36”
  • 81.169.250.132 – – [03/Apr/2024:18:35:30 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.5 Mobile/15E148 Safari/604.1”
  • 203.245.28.189 – – [03/Apr/2024:18:35:33 -0700] “POST /index.php?TgAD=utRBi HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/115.0.5790.130 Mobile/15E148 Safari/604.1”
  • 148.113.173.205 – – [03/Apr/2024:18:35:39 -0700] “POST /?Zzw=AUFBo HTTP/1.1” 301 244 “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 16_3_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Mobile/15E148 Safari/604.1”
  • 51.91.44.167 – – [03/Apr/2024:18:35:43 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36”
  • 208.113.205.120 – – [03/Apr/2024:18:35:44 -0700] “POST /index.php?WeXQ=yuej HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36”
  • 184.168.118.22 – – [04/Apr/2024:00:07:17 -0700] “POST /[redacted]/wp-content/themes/qop043n9/cbgyjuye.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 11; SM-A202F) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.62 Mobile Safari/537.36”
  • 142.93.14.237 – – [04/Apr/2024:00:07:25 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (Linux; Android 10; SM-A405FN) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Mobile Safari/537.36”
  • 198.57.247.188 – – [04/Apr/2024:00:07:26 -0700] “POST /[redacted]/wp-includes/rest-api/themes.php HTTP/1.0” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”
  • 185.162.31.173 – – [04/Apr/2024:00:07:30 -0700] “POST /[redacted]/wp-includes/Requests/bsqukfha.php HTTP/1.1” 404 – “http://[redacted]/” “Mozilla/5.0 (iPhone; CPU iPhone OS 13_1_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.1 Mobile/15E148 Safari/604.1”

The hacker tried to access over 30 different backdoor files that they placed on the website. It isn’t uncommon for many of those files to have been added and for them to be placed widely across the website’s file structure, as was the case here. Because we had already cleaned out all of those files, the hacker was unsuccessful in regaining access.

Also notably there, the hacker was making the requests from many IP addresses, which is a good example of why trying to stop hackers by blocking access to certain IP addresses is not an effective security measure. (The requests also made it look like the request were coming from a variety of web browsers.)

If you need help with a hacked WordPress website, we can help you.

Resetting the WordPress Password When WordPress Can’t Send Emails

We were recently contacted by someone who needed support for their WordPress website, where they were locked out of the website and needed to change their WordPress password. We suggested they use the “Lost your password?” link on the login page to reset the password. They said that didn’t work. It turned out that when you tried that, you got shown this message:

Error: The email could not be sent. Your site may not be correctly configured to send emails. Get support for resetting the password.

That message is saying that WordPress isn’t able to send emails. Without that ability, the password reset feature doesn’t work.

So how do you address that? To fix the email issue, you are likely going to need to be able to log in to WordPress as an Administrator. If there is only one account, then you won’t be able to do that because you are locked out. Even if you are not, fixing that can take some time, so it is easier to reset the password another way before addressing the email issue.

The error message links to a documentation page for WordPress on resetting the password. That explains multiple alternative methods to reset the password. All of those require at least minimal technical expertise, so you may want someone to help you with that. That is something we can do for you, alongside getting the email for the website working.

How to Safely Remove Malware From a WordPress Website

If you have malware on your WordPress website, you are not having a great time and you don’t want to make the situation worse by causing more problems when removing it. From our years of cleaning up hacked WordPress websites and dealing with the aftermath of others not doing a good job of that, there are some important tips we can share.

Make a Backup of Everything First

Before making any changes to the website, make a backup of everything. That usually means making a backup of the files on the website and the database. That way, if a removal effort goes wrong, you can always revert back to where you were before it. It’s worth the time to do this before doing anything else.

We wouldn’t recommend doing this with a WordPress backup plugin, as those can be less reliable methods to generate a backup.

Don’t Overwrite the Website with a Backup You Think is Clean

One common suggestion to deal with a malware infected WordPress website is to revert to a clean backup of the website. There are a couple of common problems with that. First, often you won’t know if the backup is clean, as you probably don’t know when the hack started, only when you noticed it. Second, if you overwrite the files on the website, you can end up with the new malicious files still being on the website. You need to make sure you clear everything out first and put the backup files on the website, instead of overwriting the files. If you overwrite the files, you can also have other problems with files existing that shouldn’t exist together.

Make Sure The Person Removing the Malware Knows What They Are Doing

While it would seem fairly obvious to say you should hire someone experienced in dealing with removing malware from WordPress websites to clean it up, the reality is that there are lots and lots of providers who are not doing things right. You might get lucky and hire someone like us who does things right, but there is a good chance you will hire some who won’t. So either make sure that the provider not only removes the malware but also tries to secure things as much as possible, and most importantly, tries to determine how the website was hacked. If a provider doesn’t emphasize that they do the last element, they should be avoided.

If you are looking to do it yourself, there are lots of guides out there on doing that, though, from what we have seen, that don’t do a good job. A lot of them look to be there to ultimately get you to hire the source of the guide after their advice doesn’t work. Others are written by people that don’t appear to have experience actually dealing with removing malware. Either way, you might get lucky with their advice, but you might not, leading to more work needing to be done.

Try to Figure Out How the Malware Got There

If you remove all the malware, but the source of the infection isn’t addressed, you can quickly have malware on the website again. This is something that often isn’t done, including with lots malware removal services. One of the reasons we know that is that when we are brought in to re-clean malware infected websites, we check the logging and often find that it shows malicious files being accessed that were missed in the previous cleanup.

A WordPress Website That is Hacked and Redirecting to Another Website May Redirect Intermittently

While we are often contacted to deal with cleaning up hacked WordPress websites, we also often run across hacked WordPress websites when we are contacted about doing other work. We mentioned a recent instance where a WordPress website that was running slowly was hacked. In another instance, while checking on a website to see what software it was running, we got redirected to another website. What was going on? The website was hacked, but determining that isn’t always easy from the outside, as the redirects can happen intermittently and you don’t necessarily have any other way of spotting the hack from the outside.

While some redirects occur because of JavaScript code being loaded by a web page, so you can see the code even if it doesn’t cause a redirect in a particular instance, others occur before the web page loads. When the redirect occurs can vary. In this particular situation, the redirect had happened for us when we directly accessed the website, but didn’t happen the second time. The results of a tool we have to check if website are redirecting from Google showed the same pattern. Here was the result of that the first time we requested the page:

The details of that are not going to mean much to those not familiar with HTTP headers, but what is going on is that when requesting the page from Google the request was being temporarily redirected (a 302 redirect) to Location: https://ootooghangoh.shop/?u=k8pp605&o=c9ewtnr&t=ggdown.

A temporary redirect just means that web browser (and other systems) shouldn’t store the redirect and automatically redirect the next time.

When running the same request again, the redirect didn’t happen again:

In both cases, trying again few hours later, the redirect again occurred with the first attempt, but not on subsequent requests.

In other situations, the redirect might only in other situations, including only requests from mobile devices.

Just to make it a bit harder to determine what is going on, it is also possible that there is malware on someone’s computer that is causing a redirect.

If you are unsure of if your WordPress website is hacked, please contact us to get a second opinion on your belief that it might be hacked.

Various WordPress File Upload Functionality Being Abused by Web Spammers

Last week, we looked at various methods that spammers are using to place spam pages and other content on websites. That includes abusing web software, such as a Drupal module on websites from high-profile universities, and a feature of the Wix website builder service. It wouldn’t be surprising to hear that WordPress websites were also involved considering how widely used the software is and how many plugins there are that extend it that might not be hardened against abuse.

In checking over things, we noticed that a website from John Hopkins university had this happen with the Formidable Forms plugin. The website did block access to the uploaded file, with this message:

You are receiving this message because your request triggered one of our security firewall policies. Johns Hopkins faculty and staff may try accessing this page through the JH Pulse VPN Johns Hopkins VPN or MyCloud. If these methods don’t work, contact webhosting@jhu.edu and provide the full URL and support ID below.

Your support ID is: 3030507284814651859

[Go Back]

On a Princeton website, based on the location of the file, it looked like the plugin WP Feedback, Survey & Quiz Manager, later renamed to eForm was the source.

On a website of Southern Illinois University Edwardsville, the file was uploaded to WordPress’ standard directory for uploaded files. Making it unclear what the source was.

The situation is a good reminder that even if file upload functionality is secured to prevent malicious files being uploaded and a hacker taking over the website; it is still possible for file upload functionality to be abused. If you have file upload functionality, where the file uploads don’t need to be web accessible, making sure they are not accessible that way stops web spammers from abusing it.

If you have a website that has web spam content placed on it, we can help you to get it cleaned up and hardened to avoid additional issues.

Just Because a WordPress Plugin You Use Has a Vulnerability It Doesn’t Mean It Got Your Website Hacked

As we have talked about recently, there is often confusion over how websites have been hacked. One issue that comes up from time to time is the claim that a WordPress plugin that contains an unfixed minor vulnerability is the source of a hack. Here is one recent claim of that:

i would strongly urge you to remove it now. My site was hacked several times before I realized it was because of this plug in. It sucks because I was unable to find a replacement and have to do it by hand.

The vulnerability that is known to exist in that plugin would allow someone logged in to WordPress with the Contributor or Author role to cause malicious JavaScript code to be included on frontend pages on the website. (Higher level-users already have the capability to do the equivalent of that.)

Unless you have an untrusted individual with access to WordPress with the Contributor or Author role, either intentionally or because someone with that level of access had their account breached, you don’t have to worry about that. So the chances of that being exploited are slim.

It’s possible that the quoted individual had that situation, but almost no websites will, so the chances of the plugin being the cause of hacks on websites is very small.

Trying to figure out how a hacked WordPress website was really hacked is a standard part of our hack cleanup process for WordPress websites. Our hack cleanups include a free lifetime subscription to our Plugin Vulnerabilities service, which includes providing fixes for unfixed plugin vulnerabilities.