alligatornest

Hey wfpeter,

I’ve implemented your suggestions on our sites. By default, it looks like those rate throttling limits were set to “unlimited”.

Rate throttling should mitigate the issue I described in item 4 in my post. Correct?

I really appreciate your help.

Support,

Just to follow up on this: this morning I downloaded the .htaccess file and the load-scripts protection entry was missing again (see below). So I logged in to admin, clicked save, and the load-scripts lines were back.

# BEGIN WP CERBER GROOVE
# Protection of admin scripts is enabled (CVE-2018-6389)

# END WP CERBER GROOVE`

Thank you for this update.

I have updated the plug-in locally and it does seem to have fixed the issue. I will continue to test before reactivating the plugin on our production site.

This bug created some issues on our website that we didn’t even know to look for until they were discovered, too late, in production by our users. As a result, we have had to add a number of additional checks to help spot such issues before they go into production.

Seeing the same issue as reported by Sean Dempsey (above). Disabling the plug-in resolved the issue.

Thanks Tim. I am about to modify my work-flow so that I only push my theme changes with Git Hub and Deploy, but manually update WP Core and plugins on local -> staging ->production (testing each along the way of course). Lately, I’ve had issues with DeployHQ taking too long when pushing a WP core update, or throwing an error when pushing a plugin update (like a permissions error on Wordfence).

Does anyone else have a similar set up?