Esrblog quarantined due to webshell

The esrblog directory contained an unmaintained and vulnerable WordPress instance which security monitoring software detected as hosting a PHP web shell that was being actively exploited. Staff quarantined the directory by changing ownership and removing *nix permissions such that the web servers will no longer serve its contents.

I just became aware of this.

My blog has been frozen for six months due to a database server issue. I couldn’t even run mysql on the blog hostl access to the blog was slow and commenting entirely broken.

That’s why it’s “unmaintained”. I have rescued the content and for the last week I have been working on bring it up at other hosting, because I had pretty much given up on the server issue being addressed. If you’re paying more attention now, would you please fix it?

Please do a fresh install of WP there to clear out the malware. I’d do it, but I cannot with the directory locked.

It would be best if we could preserve the old content in place, but if not I have recent SQL dump - you can nuke the whole site from orbit if you want and I will just do an SQL restore. That is, providing you do fix the server issue.

At this point I’m disgusted enough with WordPress that I plan to migrate my blog to something like Jekyll or Hugo. But an orderly transition that doesn’t break peoples’ inbound links to my content would be very desirable. I’d like the blog back up ftemporarily so that can happen.

An infosec specialist I know furnishes a clue: he says there hasn’t been a publicly revealed exploit in base WP since 5.4.1. Therefore either the attacker had a zero-day (unlikely) or one of the plugins I was using is vulnerable.

So don’t bother restoring the plugins, except Akismet which he says is pretty solid - no exploits since 2015.

As previously mentioned, in order to use PHP, mysql, and other newer-than-default tools, on one currently needs to use scl. Rather than change your ~/.bashrc, there’s a separate file you can source. If you wanted to source it by default, you could simply add . ~/.enable_scls to your ~/.bashrc and it would be picked up at next login. The file is just two lines:

$ cat ~/.enable_scls
  source scl_source enable rh-php73
  source scl_source enable rh-mariadb101

Plugins as I found them this morning:

akismet       hello-dolly  jetpack               quotes-collection       tip_jar.php            wp-plus-one
commentsvote  index.php    live-comment-preview  simple-comment-editing  wp-import-export-lite  wp-syntax

I’ve left akismet and hello-dolly and deleted the others.

esr@login2:esrblog$ wp plugin update --all
Enabling Maintenance mode...
Downloading update from
Unpacking the update...
Installing the latest version...
Removing the old version of the plugin...
Plugin updated successfully.
Disabling Maintenance mode...
| name    | old_version | new_version | status  |
| akismet | 4.1.6       | 4.1.9       | Updated |
Success: Updated 1 of 1 plugins.

I’ve chowned the directory back to you, but I haven’t given read/execute perms back such that the web server will serve the site. Our preference is that you review the site at your leisure and let us know when you’re confident it is safe to restore.

It’s unclear to us what database server issue you’re referring to. Possibly you mean you were unable to use mysqldump or other tools from the login host, in which case this post might be helpful.

I’m on it. Have enabled wp as instructed and used it to verify that the PHP is updated.

I’m reviewing the content directories now. I know of one very minor issue from looking at the snapshot I took last week, but it’s just a Russian porn spam link in a header widget - I’ll have that fixed in 30 seconds once the site is live again.

Now reviewing the content directories for anything suspicious. Will get back to you shortly.

Everything looks good. No suspicious dotfiles or dodgy permissions, nothing funny-looking in the plugins or uploads directories. Unless somebody has a novel crack on WP 5.7 I think we are safe to resume.

I’ll delete that Russian porn link as soon as I learn from you that the site is live.

The esrblog directory has been enabled again, but note that the permissions on the uploads directory and its sub-directories are still set such that uploads from the web interface will fail. If you wish to add items to your uploads, we suggest using sftp or rsync to place them there via login.ibiblio for now. Thanks for the quick response and attention on this.

Thanks. The database issue is only half-resolved, though. Posting and commenting are extremely slow, with lag in the tens of seconds.

While that’s better than before (blog was completely stuck) I’m going to move forward with my plans to rehost it and use a different blog engine.

See plan.adoc · master · Eric S. Raymond / blogpiper · GitLab

I intend to get shut of WordPress just as soon as I can write the code to do the migration.

You asked about the database issue. Commenting is still broken. One of met regularsmm Duncan Baynem sent me email to say this:

“I posted a single comment (in reply to your test comment), and received
a rate limit error from Wordpress.”

It helps to have a timestamp to compare to logs, and if possible a set of steps to reproduce. Is it all commenting, for example? Thanks.