AlSimons

Testing with Gutenberg and 5.0.1, my notification on my test site worked.

HOWEVER, I had also gotten a notification running 5.0.0 with a Gutenberg post, so take my success with a grain of salt.

-Al

Following.

Thanks to the team for getting a fix incorporated for this. We appreciate it.

Here’s what I did to stop the spam emails. While the updated plugin should fix this particular case, what we have been seeing is a successful attack through a method that would remain to use against other plugins. I’ve shut down the method that was used here so it can’t be used for future attacks.

This will work for people who have access to the file system at the hosting site, and who are comfortable editing configuration files.

IF YOU MAKE A MISTAKE EDITING THIS FILE, YOU CAN BREAK YOUR SITE, in ways that are difficult to diagnose.

BEFORE YOU DO ANYTHING, MAKE A COPY OF THIS FILE SOMEWHERE!

The file involved is .htaccess (notice the leading period), in the directory that contains wp-admin, wp-content, etc.

When I looked at my access logs, I noticed that there were many connections using the curl user agent. Curl is a command-line program to access web sites, that is singularly unsuited to looking at WordPress sites. No valid user will be coming in this way. What’s going on? I also noticed that there were curl HTTP POST operations, which is how data are sent to a website (as opposed to getting information from the site), and the timestamps of those POSTs matched the fake subscriptions. Bingo!

So I closed down curl access to my site, by adding these lines to the top of my .htaccess file. It must be before the lines added by WordPress.

# Added to stop curl access!
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^curl
RewriteRule ^.* – [F,L]
# End of curl elimination

I’ve now gone 18 hours with no new fake subscriptions; unheard of in the past few weeks.

As I said earlier, this cuts out a broad class of attacks, and in my opinion is worthwhile even when we have the new plugin.

Hope this may help some people, and again, THANK YOU to the team for this plugin and the upcoming fix for this problem.

-Al

This is getting more critical. My blog address is now marked as a spam site because of all of the confirm emails being sent out–several hundred a day.

We all need workarounds.

Does the team know the path by which these are coming in? Would it help to put a .htpasswd file on /wp-admin?

Is there a way to make a group not require the confirmation email, yet require it for the group we really use (the fake subscriptions are all in the public group, which I don’t use).

Is it possible to delete the public group and would doing that prevent these subscriptions, or would it simply be re-created?

I hate to end it this way, but the problem is very serious for us. If you can’t help us all shut this problem down, can you suggest an alternate subscription plug in we can switch to?

Thanks,
-Al

Thank you, team, for working on this issue. For at least my bogus subscriptions, the email address is non-existent. You may already be doing this, but a possible approach in addition to the steps you are already taking might be to send an SMTP VRFY command to the address right up front, and if an error is returned immediately stop processing the subscription request. If it is being done through the form, you could present an error dialog; otherwise silently ignore it.

Again, thanks for the plug-in and your continued work on it for our benefit.