Recently a Sucuri Firewall Security Team uncovered a vulnerability in WordPress which allows unauthenticated users to make changes to any WordPress page or post within a given site. This was considered to be a content injection vulnerability (or a privilege escalation) which affected the WordPress REST (Representational State Transfer) API, that was added to WordPress version 4.7.0 and enabled by default. A specific endpoint in the WordPress REST API permits users to view, create, edit, and delete any given post, and it can be extended to include any other post or page on the entire site.
When WordPress security personnel were alerted to this deficiency, they quickly moved to prepare a patch that would close up the loophole and secure pages and posts against attack. The patch was included in version 4.7.2 without a lot of fanfare, so by now most WordPress users should have the patch in place, assuming that they allow automatic updates from WordPress, or that they manually selected this version for installation. Obviously, any site which fails both these criteria would not have the patch, and sites running either version 4.7.0 or 4.7.1, would thus still be vulnerable to external attack.
Details Of The REST API
The WordPress REST API is used to allow other websites, mobile apps, and other servers to retrieve data easily without having to use a browser to visit the website. It provides an easily used collection of endpoints which permits access to your site's data, including posts and to other users, making the retrieval of data as easy as sending a basic HTTP request. A typical usage of the REST API would be for an authenticated user to update a blog or to create a new one, using the API interface, while an unauthenticated user should receive a 401 'Unauthenticated User' message, with subsequent denial of the post request.
Exploitation of the vulnerability within the API is attributable to a concept known as 'type juggling', which allows the type of data entered to be determined by its context. Within the POST schema of the REST API, there is an ID object entry which is defined as being of type 'integer', but there were at least two locations in related files where the ID object was not firmly cast as an integer. The unfortunate result of this weakness is that by including this ID parameter in a POST payload carrying a non-numeric character, all authorization checks are bypassed.
Fixing The Bug
The obvious correction to this vulnerability, and the one which was adopted by the WordPress security team, was to track down all files where the ID parameter was not correctly cast as an integer, and force the integer typing. Once this fix was put in place, the vulnerability was locked down and authentication was once again secure. Any organization which is currently using either of the two affected versions of WordPress mentioned above, could still be vulnerable to attack if it hasn't allowed the automatic updates to be installed, or is not on WordPress version 4.7.2, where the bug has been fixed.