redsand

Hi Mike,

I can definitely understand that. Please remember that WP-SpamShield is a security plugin, and sometimes security alerts might be alarming. To be honest, a security alert should be alarming. It’s not something you want to ignore. Security issues require action.

The alert shouldn’t show up more than once per week per site, as long as the exploit is unpatched. Once it’s patched and the site is upgraded, it won’t pop up. (As long as there are no known exploits in the new version.)

I would recommend checking your clients’ server configurations, and making sure they are configured properly so as to nullify the exploit. You may want to implement one or more of the mitigation methods mentioned above. Once you’ve ensured that the client servers are no longer vulnerable, then you may want to email each of your clients a short note about the alert explaining that yes there is an unpatched exploit in WordPress, but that you have taken steps to mitigate the issue. Once this is done, let them know that their sites are safe, and that they can safely ignore the alert until WordPress releases a new version with the patch.

If you have any further questions or issues, please use the WP-SpamShield Support Page and we’ll be happy to help.

– Scott

Hi Mike,

WP-SpamShield periodically checks the WPScan Vulnerability Database for WordPress exploits, and if the site’s WordPress version has a known vulnerability, then it will alert the admin.

WordPress currently has a 0-Day Exploit that has not been patched.

This is a legit security issue. The link you posted above explains the issue. You can also see these for more info:

WordPress Security Issue in Password Reset Emails to Be Fixed in Future Release — WordPress Tavern

Unpatched WordPress Password Reset Vulnerability Lingers — Threatpost

If a server is configured properly, it won’t be an issue. A properly configured server won’t allow requests with faked Host header requests, and will ensure that $_SERVER['SERVER_NAME'] does not get overwritten by a user-supplied header. However, many servers are not configured properly.

The WordPress Tavern article discusses one mitigation technique using code added to a plugin or your theme’s custom functions.php file. (It’s recommended to use a child theme if you do this.)

The risks can be mitigated in a couple of other ways as well.

One is easily done in your site’s .htaccess file.

If your site’s domain is “www.yourdomain.com”, the code would look like this:

RewriteEngine On
RewriteCond %{HTTP_HOST} !=www.yourdomain.com
RewriteRule ^/?(.*)$ https://www.yourdomain.com/$1 [R=301,L]

This ensures that your site only functions when the correct Host header is used, which would effectively prevent the exploit from being used.

Notes:

• Place this code near the top of your .htaccess file.
• Replace www.yourdomain.com with your site’s preferred domain. (www vs non-www)
• If your site does not use https (SSL/TLS), then replace the https with http.
• If your .htaccess already has RewriteEngine On, then you can skip that line, as it only needs to be included once, before the first RewriteCond/RewriteRule set.

I would encourage you to request that the WordPress Dev team fix the issue as soon as possible.

The next version of WP-SpamShield will include a mitigation patch for this 0-Day so that at least all WP-SpamShield users will be protected.

I hope this info helps. If you need any further help, please submit a support request at the WP-SpamShield Support Page and we’ll be happy to help.

– Scott

This is like arguing about why Apple software doesn’t run on Microsoft, and vice verse. Not exactly constructive, and been done to death already. Not gonna do Nginx vs. Apache arguments. Stackexchange is probably a better place for that.

Your conflict page does not list anything concrete or evidence that the plugin would break on nginx standalone configurations.

It does if you read the whole thing and the linked articles. I’m not going to re-hash things that are already explained in the docs, but I’ll be happy to answer questions if you want to submit a support request.

Also, I checked your .htaccess files and as I said previously: All of it could be “translated” to Nginx, as all you do is apply access restrictions (mod_authz_core), compression (mod_deflate) and some headers (mod_headers).

Again, that’s not accurate either…you’re missing some things. Like I said, there is a lot more to it than you may realize.

You blocking Nginx just for being Nginx makes no sense.
You are just pushing Apache for no apparent reason.

It won’t make sense if you aren’t intimately familiar with the nuances of the two servers. That whole argument is an oversimplification and is still not accurate. We’re not “blocking” Nginx. It just doesn’t have the requirements. Simple as that. Apache and Nginx have different benefits and drawbacks, and there multiple ways to employ them.

We are working on creating an anti-spam plugin that is specifically for Nginx, so saying that we “block” Nginx, are “pushing Apache”, or are anti-Nginx, is ridiculous.

I’m not going to argue with you here, but if you have specific questions, we’ll be happy to answer them if you’d like to submit a support request.

Take care.

Hi Paul,

I’m sorry to hear about the issue you’ve had.

I know you posted that you’re using 1.9.9.9.7, but that error is for version 1.9.9.9.6, and was remedied immediately in version 1.9.9.9.7. Please see my response here regarding that issue. If you upgrade to 1.9.9.9.7, it will resolve the issue.

Also, please note that if your site is using a standalone Nginx server does not meet the plugin’s minimum requirements, and is not compatible with WP-SpamShield:

3. Your server must be configured to allow the use of an .htaccess file. The vast majority of users will have no issue here, because most web hosts allow this by default. However, if yours does not, you will need to contact them and ask them to enable it on your site. If they won’t, then it’s time to get a better web host. WordPress loses a lot of functionality if you don’t have use of .htaccess enabled, so this is important for full functionality of WordPress and other plugins as well.) Note: By definition, a standalone Nginx server would not meet this requirement, but an Apache/Nginx hybrid setup would. (Nginx is setup as a reverse-proxy in front of Apache. This type of setup offers high-performance and is recommended.)

WP-SpamShield has not ever supported standalone Nginx, and this is explained in more detail in the Known Issues and Plugin Conflicts.

If you have any further issues, please submit a support request at the plugin’s official support page, and we’ll be happy to help you resolve it.

— Scott