If you want to understand why security, whether related to WordPress plugins or more broadly, is in such bad shape looking at the state of security journalism would be a good place to start. What you will find with WordPress plugins is that there are frequent stories telling people to update or remove plugins after they have already been widely exploited, which is too late. You might think that journalists would stop and think about that and realize there what is going on isn’t working (there is a line about the definition of insanity that comes to mind), but it doesn’t ever seem to occur for them. If anything they seem to think trying to better address the situation is a bad thing. For example, earlier today we mentioned that a journalist was criticizing us for having spotted a hacker targeting a plugin and then publicly warning everyone about that before there was confirmed exploitation. If journalists were actually interested in doing good journalism another element of that post is worth covering, as a new version of the plugin that fixes the exploited vulnerability has been released, but the WordPress is not allowing those using the plugin to get access to it.

That plugin was part of what looks to have been a set of nine plugins so far that a hacker has been recently looking to exploit. With another of those, Simple Fields, we saw what looked to be the hacker probing on the September 15 and we warned about a persistent cross-site scripting (XSS) vulnerability that it looked like the hacker would be interested in exploiting the next day. Other security providers still don’t seem to be aware of the issue (they at least have not warned about the issue), even though there is now public confirmation that it is being exploited. What that shows is not only how our service can often help to avoid websites being hacked by warning before the hackers exploit vulnerabilities instead of after, but also that we can help to address security situations that are beyond the scope of the average webmaster on their own.

Yesterday a new topic was created on the WordPress Support Forum, “Hack related to Simple Fields?“, which indicates that a hacker had exploited this vulnerability on this person’s website in the last day:

I noticed today our website had problems, and yesterday it was fine. I was about to add a new post for a custom post type, the same as I had done yesterday, but I noticed none of the special fields that come from Simple Fields were where they were supposed to be on the edit page. It looked like a plain edit page.

If they had been using our service they would have been warned about the vulnerability a week before that.

Later in their post they write:

We did have a backup that we reloaded successfully, and we’ll have more things to add back in since the last backup, but that is doable. However, we don’t know how this could have occurred and we don’t currently have a way to prevent it from happening again.

I just noticed on the plugin page –
https://wordpress.org/plugins/simple-fields/
It says in red background –
“This plugin has been closed as of September 16, 2019 and is not available for download. This closure is temporary, pending a full review.”

That is recent and it is interesting that it is a temporary closure and there will be a review. Perhaps someone is aware of a serious problem. Does anyone know more about this?

And near the end of their message they say this:

I don’t even know for sure if the Simple Fields plugin was the original vulnerability, but that is my best guess. We will check web server and network logs.

I guess if there is no short-term solution, then the long-term solution for us would be to use an alternative plugin to Simple Fields. That would be a huge undertaking.

Again if they were using our service they would have been warned about the vulnerability a week before that, so they would have known what was going on before being hacked. But we would also been able to help with dealing with the situation, as an important part of our service is the support we provide when a plugin being used is found to be vulnerable. Whether that be making an assessment that the plugin was simply too insecure to keep using or providing them with temporary fixes that could be made to the plugin to secure it enough to keep using for the time being (it doesn’t appear this plugin is being supported anymore).

Because of the inappropriate behavior of the moderators of that forum, not surprisingly they so far have not gotten a response from someone who could help them to understand what has happened. Instead the only response they have gotten so far is from someone else impacted by this:

We are having similar issues as well.