As I mentioned on Friday, WordPress version 4.9.3 was released as scheduled Monday mid-day. If you have auto-updates enabled, you might have been surprised to see another WordPress update (4.9.4) come through Tuesday morning around 10am (CST). It seems there was a severe bug in 4.9.3 that caused the auto update feature to break in some sites and will require manual intervention to upgrade to 4.9.4. If you have auto-updates enabled and you did not see a notification of the update Tuesday morning, you will need to manually update to WordPress 4.9.4. Doing so will correct the issue and allow the auto-update feature to work for the next release.
Separately, a denial-of-service vulnerability was disclosed yesterday that takes advantage of a default feature in WordPress to overwhelm the server targeting the load-scripts.php and load-styles.php files. Those two files will load up all requested scripts/styles and dynamically concatenate them into one file. The vulnerability comes into play when a request is given to them to load every possible script/style. There are 181 scripts included in core. Instructing the script to read and concatenate that many files into one file, for most hosts, will overwhelm the resources and cause the server to return 500 errors. According to the researcher, the WordPress security team didn’t consider it a core vulnerability and believe it should be handled at the server/host layer. The probability of someone legitimately enqueueing that many scripts/styles is probably fairly low, certainly lower than the probability of someone abusing this feature to cause issues. It should be entirely possible for core to limit the number of files being concatenated to X amount, with the ability to increase the number if problems are encountered.
In response, the researcher has forked WordPress with his fixes and has also provided a patch, but I would not suggest using a forked version of WordPress. While the patch is straight-forward, it will require being reapplied after every update (so twice this week). Instead, I would suggest adding a couple of lines to your htaccess file to watch for requests to these file, and block them if the length of the load list is too long.
RewriteCond %{REQUEST_URI} ^/wp-admin/load-(scripts|styles)\.php$
RewriteCond %{QUERY_STRING} load(?:\[\])?=(.{256,})$
RewriteRule ^(.*)$ - [F,L]
In the full list of scripts, there are 2650 characters. In the above htaccess example, I’ve set it so if there are more than 256 characters forbid the request. You may need to adjust that number upwards if you find your loaded scripts list is longer.
If anyone is experienced in nginx conf files and can translate the above to nginx equivalent, reach out to me, and I'll post it here.
UPDATE: small update to the regex. Hat tip to Matt Pierce for catching the oversight.