WordPress 5.0.1 and 4.9.9 released

Exactly one week after WordPress dropped their major release version 5.0 security patches have been released in the form of 5.0.1 and 4.9.9.

Several security issues have been addressed in the 5.0.1 update which has been backported to version 4.9.9 for those who have yet upgraded to WordPress 5.0.

Among these security fixes, as outlined on the WordPress site:

5.0.1 was released to fix several security bugs. The Security team tried very hard to mitigate all of the vulnerabilities without any back-compat breaks, but unfortunately there were a few cases where that was not possible. Form element no longer passes KSES.

Prior to 5.0.1, the $allowedposttags array contained an entry for the <form> element and some of its attributes. Because of that, Contributors and Authors could use it in posts.

The element was removed in 5.0.1, except for situations where a plugin has explicitly registered input or select fields via the wp_kses_allowed_html filter. If a Contributor or Author includes <form> in their post, it will be removed when the post is saved. It will also be stripped from arbitrary content that plugins pass to wp_kses_post() or wp_kses_allowed_html( ‘post’ ).

If a plugin author wants to restore the original behavior, they will need to add form, input or select tags via wp_kses_allowed_html. Please exercise caution when doing so, because this could re-introduce a vulnerability. Make sure only trusted users are allowed to add <form> tags. meta_input, file, and GUID inputs are ignored

Prior to 5.0.1, $_POST requests for creating posts could contain values for meta_input, file, and guid. This is no longer true, and values passed for those fields will be ignored.

Plugins should not manually manipulate $_POST, but rather use the appropriate filters, and always validate/sanitize any data coming from an untrusted source. MIME validation for uploaded files

Prior to 5.0.1, WordPress did not require uploaded files to pass MIME type verification, so files could be uploaded even if the contents didn’t match the file extension. For example, a binary file could be uploaded with a .jpg extension.

This is no longer the case, and the content of uploaded files must now match their extension. Most valid files should be unaffected, but there may be cases when a file needs to be renamed to its correct extension (e.g., an OpenOffice doc going from .pptx to .ppxs).


We have tested WordPress 5.0 on several web sites and have been closely monitoring the discussion boards for compatibility issues of which we have seen only few. Based on what we have experienced we feel comfortable rolling out WordPress 5.0 to our clients at this time. We actually enjoy using the Gutenberg editor, which this post was written in but also understand that it may not be right for everyone. Therefore we will also be installing the Classic editor on all sites we upgrade.

As always, please let us know if you have any questions.

Leave a Reply

Your email address will not be published. Required fields are marked *