We've updated our policy regarding how we treat and protect data that is collected and used from our websites. This site also uses cookies which are necessary to its functioning and required to achieve the purposes illustrated in the policy. By using this site you agree to our use of cookies. Please read our Privacy Policy for more information and your related choices.

WordPress White Screen of Death (WSOD)

WordPress has a security problem. Over the last few years, hacking has become a common-place problem in the WordPress space. It's not that WordPress's core is extremely vulnerable (though it can be at times) but all of the third party elements baked into WordPress's infrastructure coupled with widely available source code is a recipe for disaster.

To combat these growing concerns, WordPress has been working to develop security measures aimed at combating some of the lower-level concerns. For instance, WordPress's new "white screen of death" (actual name) feature is coming with patch 5.1 — due in Spring.

This new feature was originally designed to give users recovery options after the new PHP migration (and subsequent discontinuation.) But, they've also decided to bake the feature into their plugin and themes by forcing all plugins/themes with PHP issues to stop running when they encounter issues.

So, what's the problem? Well, a few weeks ago, security researchers started to question some of the uses of these new features, and how the white screen of death may actually make WordPress sites more vulnerable.

Understanding the "White Screen of Death" Feature

The migration from PHP 5/6 to PHP 7.x presents a few issues for WordPress users. First, many WordPress plugins/themes are starting to discontinue PHP 5x support — especially paid plugins (e.g., CodeCanyon.) Second, PHP 5.x is no longer receiving security support.

For WordPress users, this means that PHP issues are on the horizon. In an effort to combat this, WordPress announced a new feature that would help disable plugins or themes that presented PHP issues. Since many WordPress plugins and themes still use the antiquated PHP version, users switching to PHP 7.x for security reasons may suffer issues with plugins and themes.

The new security feature — set to launch in 5.1 this spring — is called the White Screen of Death Protection (or WSOD.)

Here's how it works.

If a plugin or theme is running the older version of PHP and runs into an issue due to version differences, the plugin will be locked down and the site will display a white screen prompting the administrator to log in and fix the issue. During the detailed briefing of the update, WordPress core developer Felix Arntz described that the new feature wouldn't only apply to the new PHP issue, it's a system-wide security feature.

"While the primary reason for implementing the fatal error protection mechanism was making the process of updating PHP less "dangerous", it is technically not tied to the update at all. In fact, it will be enabled permanently and discover fatal errors under any circumstances." — Felix Arntz

So, this new security feature will attempt to stop any plugin or theme that's "misbehaving" from running, stop it on the backend, and display a message on the front end prompting the site owner to log in and mitigate the issue.

What's the Issue?

In theory, the idea of containing vulnerable plugins is a fantastic idea. But, some security experts aren't too sure that this new system will help. In fact, many believe that the WSOD is ripe for misuse.

Sucuri researcher Slavco Mihajloski posted a blogpost on Medium last week warning WordPress of some potential issues that the change may bring.

Since the WSOD is capable of disrupting the functionality of any "misbehaving" plugin, attackers would be able to use the feature to bypass firewalls and other security elements baked into a WordPress website via plugins.

For example, if attackers were to misuse the WSOD, they could disrupt a website's security plugins to bypass their firewalls, making it easier for them to hijack the website via vulnerabilities.

Slavco Mihajloski isn't the only researcher who noticed these potential issues. In a bug discussion thread on WordPress.org for the new feature, Matt Rusnak from WordFence detailed some immediately concerning issues with the feature.

"For login and security-related plugins, pausing the plugins could be worse than letting them run normally, especially if the error is only caused by bad input from an attack or a bot. I'm most concerned about security plugins getting paused."

Matt went on to detail three specific attack paths that presented an issue.

  • 1. A plugin may be paused because another plugin used a lot of memory.

  • 2. Local File Inclusion vulnerabilities in any plugin/theme will give the attacker the ability to pause many plugins at will

  • It might be possible that max_execution_time has the same issue as memory_limit

In response to these issues, WordPress promptly made changes that allowed the WSOD to be disabled via WP_DISABLE_FATAL_ERROR_HANDLER in wp-config.php.

The Implications

This new security feature is a short-sighted response to a major issue. WordPress's open source nature leaves it incredibly vulnerable to the upcoming PHP update. Not only does the architecture of WordPress rely on scattered third party plugins and themes that act in disconnected environments, but these themes and plugins aren't held to any particular standard. Thousands of themes will be running an older version of PHP and causing frictions related to the new update.

This isn't something that's WordPress's direct fault. It's an intrinsic part of open source content management systems. With a web of fractured and modular environments, it's difficult to set standards-of-security.

As it stands, WordPress is already having rampant vulnerability issues in the plugin community. But, overarching responses such as these are an unnecessary attempt at fixing a problem that's baked into the system. Security on WordPress only exists granularly — with security elements like plugins.

Until this get this new feature working properly, we recommend all site owners disable the WSOD feature after you've updated your PHP versions. It could be used as a vulnerable element to hijack your website and install backdoors. This is especially true if you have security elements installed.

Are you sick-and-tired of dealing with vulnerabilities? Do you wish that you could ensure that your website was protected from nefarious hackers? Contact us. We're a close source CMS that's dedicated to security, simplicity, and functionality. We may not have a million plugins, but we also aren't the most hacked CMS on the planet.

Update: Felix Arntz pulled the PHP Site Health mechanism off-of-the-table citing a " high number of follow-up tickets and associated security concerns". Currently, the WSOD is still active on GitHub and slated for a future release (5.2)

Related posts

  • Jun 5, 2018, 12:00 AM

    We’ve all heard it before: WordPress is “not secure.” The same claim has been made about other open source content management systems (CMS) such as Drupal and Joomla. But WHY is WordPress not secure?