Backwards Compatibility Breaks in 5.0.1

5.0.1 was just 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.

Security patches are backported to the 3.7 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"., so these BC breaks also apply to versions 4.9.9, 4.8.8, etc.

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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party has explicitly registered input or select fields via the wp_kses_allowed_html filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. 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. Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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).

#5-0, #5-0-1, #dev-notes