This bug is being exploited by “hackers” who have used it to download the private “wp-config.php” file of many WordPress sites. It’s then possible to use the private information in that file to login to your WordPress dashboard without knowing the password, or to modify your site’s database.
We’ve added firewall rules to block downloads of that file via the bug, but in addition, we’re taking the following steps to protect our customers who were using a vulnerable version of the BackupBuddy plugin at any point between August 26 and September 8:
Changed the backend WordPress database password to a new random one; and
Changed the WordPress “salts” in the wp-config.php file.
These are the steps recommended in the post by the BackupBuddy authors, so our customers don’t need to do this themselves. (The post also suggests an optional third step, but that doesn’t apply to most WordPress sites.)
The only difference affected customers should notice is that WordPress may ask for your normal password again the next time you login, rather than “remembering” you from a previous login.
Finally, keep in mind that we already make daily backups of your website at no extra charge. We never want to discourage people from making their own additional backups, but those extra backups are most useful if they’re stored in another location (not just on the same server you’re making a backup of). While investigating this, we noticed that most people using BackupBuddy are simply storing an extra copy on the same server, which doesn’t add much protection against data loss. If you make your own backups, you should ideally copy them to your own computer, or to an external location like Dropbox.
The PHP developers recently released version 8.0.22 that fixes several bugs. We’ve upgraded the PHP 8.0 series on our servers as a result.
In addition, we’ve added support for PHP 8.1 (currently version 8.1.9). We consider PHP 8.1 to be only experimental for now; it still has incompatibilities with many scripts, including WordPress, and should probably not be used on production sites. If you try it and have any trouble, we recommend you simply switch back to an earlier version of PHP in our control panel.
As always, don’t hesitate to contact us if you have any trouble.
If you use WordPress, and you allow strangers to register for WordPress accounts (which isn’t usually a good idea, but some plugins require it), it’s possible to accidentally configure it so that those new users get created as WordPress administrators. That can happen simply by doing this:
We don’t think it’s reasonable to ever create new users as “Administrators” by default, regardless of whether you have “anyone can register” turned on. (Even if “anyone can register” is turned off now, it would be easy to turn it on later without remembering to change the default role back.)
To make sure our customers’ sites stay secure, we’ve added some protections against this:
Setting the “New User Default Role” to “Administrator” is blocked at the Web Application Firewall (mod_security) level on our servers, whether from the WordPress dashboard or from any other web request;
If it somehow gets set anyway, our security systems will detect it as part of the daily security scan we do of every site;
If your site already had this setting as of today, we’ve restored it to the default “Subscriber” role.
Nobody should notice any changes as a result of this, but as always, don’t hesitate to contact us if you have any questions or difficulties.