News Courtesy of ZDNet.com:
Security researchers warn that a new feature that will ship with the next version of the WordPress CMS can be abused to disable security plugins and put WordPress sites and blogs at risk.
The feature, which has a very cool name in “WSOD (white-screen-of-death) Protection” and is considered the equivalent of a WordPress Safe Mode, is scheduled to make its debut with the release of WordPress 5.1, expected this spring.
In a blog post published earlier this week, bug hunter Slavco Mihajloski pointed out that attackers could use low-end and sometimes harmless exploits in WordPress plugins to trigger a fatal PHP error that will be caught by the WSOD protection feature.
Since the WSOD protection feature is designed to pause the faulty plugin’s execution, Mihajloski argues that attackers could abuse it to disable firewalls, two-factor authentication, brute-force protection, and other security-focused plugins installed on WordPress sites.
Ryan’s Take 
Similar to Gutenberg, this WSOD feature seems like a great idea on the surface. However, unintended consequences (like Gutenberg’s compatibility issues) will surely cause more harm than good. While it’s extremely frustrating and embarrassing to have a website crash, part of the job of a web host is to troubleshoot and remedy the issue asap.
Identifying the particular file or plugin at fault is definitely a joyless task. It may take hours or even longer disabling and re-enabling each plugin one-by-one to find the problem. So if WordPress can immediately disable the offending plugin, that’s a good thing right? It would be if it weren’t for pesky hackers.
For example, my favorite security plugin, All In One WP Security & Firewall, does several things to help secure and lockdown the websites I build. Most importantly, the rename login page feature allows me to change the standard wp-login.php to something completely random. This essentially eliminates brute force attacks. Now what if the WSOD feature was intentionally triggered causing the plugin to become disabled. Then that standard login page and other safeguards would be rendered useless.
I have to wonder if this new feature is really necessary. The affected website will still appear offline to the public. Whether the error displays PHP garble or the WSOD is irrelevant. This feature might be more useful to WordPress novices but savvy administrators can usually decipher the PHP errors and find the exact line of code that is causing the problem.
It appears for now, that the WordPress folks have taken notice of these concerns and are actively looking for a way to protect against intentional attacks. I have no problem if this eventually becomes a core feature, but at least give the option to disable it.
