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.

How to Change the Email Address that WPForms Lite Sends Contact Form Submissions To

As part of helping to deal with a problem where a contact form done through the WordPress plugin WPForms Lite wasn’t getting sent to the intended email address, we had to figure out how to change the email address the submissions get sent to. It isn’t the most clear process, so for those that have more trouble than us, here are the steps to take to change that:

  1. Log in to WordPress
  2. Go to the plugin’s All Forms page
  3. Click the Edit link for the relevant form
  4. Click on the Setting menu
  5. Click on the Notifications submenu
  6. Change the Send To Email Address setting to the desired email address.

Getting Help

If you need help with this type of problem or another problem with your WordPress website, we offer a support service to help.

Why a WordPress Contact Page Isn’t Emailing the Submissions

We were recently helping someone deal with an issue where they were not receiving emails for submissions to the contact page of their WordPress website. There are a multitude of different ways contact form submissions are handled and different ways that could go wrong, but there are three principal problems that lie at the heart of that to sort through if you have that problem. Let’s go through those.

The Contact Form Isn’t Working

The first problem is that the contact form isn’t working. So first make sure that when making a submission, it returns a response that the submission has been successful.

Depending on what plugin you are using to handle contact form submissions, the plugin may store a copy of the submissions. Or there may be an additional plugin you can add that will store submissions. If that is an option, that will allow you to make sure the submissions are really getting through and being processed.

Emails Are Not Being Sent

If the contact form is working, the next possible problem is that emails are not being sent. If you are receiving other emails from the website, you can rule that out. If you are not sure about that, you can use a plugin to test if emails are being sent. You can also use a plugin that logs emails being sent to confirm if emails are being sent.

Emails Are not Being Received

If you know that emails are being sent, then the problem that could be that they are not being received at the intended email address.

One way to test this is to try having the emails sent to another email address at a different email provider. That gives a good chance of seeing if there is a problem related to the email account. It could be that it trips a spam filter.

In the situation we were helping with, it turned out that the email account wasn’t receiving the submissions, but when switching to another account, the emails went through.

Getting Help

If you need help with this type of problem or another problem with your WordPress website, we offer a support service to help.

How to Autopost From WordPress to Bluesky

Update 9/3/24: Over at our Plugin Vulnerabilities service we did a security review of Neznam Atproto Share and found multiple security issues with the plugin. The developer so far has not addressed those.

Last week, the Twitter alternative Bluesky became publicly joinable after having previously required an invite code to join. Alongside that, there has been increased interest in automatically posting new WordPress post to Bluesky. There is a plugin to do that, though the name wouldn’t exactly suggest that. The plugin is named Neznam Atproto Share. The AT Protocol is networking technology that underlies Bluesky.

Setup is easy. On the Writing admin page in WordPress, you enter server information, including an App Password, which can be generated on the Bluesky website.

The plugin does have a major restriction we should note. It requires at least PHP version 8.0 to install it. A lot of websites are not using that version of PHP. You can get around that by manually adding the plugin in to WordPress and at least in our testing, it still seemed to work with an older version of PHP.

We have seen some complaints about problems with posting when it shouldn’t, so you should test out to make sure it works appropriately for your use case.