Earlier today we looked at how the report of a vulnerability that was supposed to have been fixed in version 1.26.2 of the plugin WP Job Manager involved something that was not actually a vulnerability. There was a change made related to what was describe in the report, but it just added additional protection over what was already in place.

The other change listed in the changelog of that version seems also to not involve something that would normally be classified as a vulnerability:

Fix: Prevents use of Ajax file upload endpoint for visitors who aren’t logged in. Themes should check with job_manager_user_can_upload_file_via_ajax() if using endpoint in templates. (https://github.com/Automattic/WP-Job-Manager/pull/1020)

Even with that change those that don’t already have an account would by default be able to upload images because of how the plugin works (the types of files that can be uploaded were already restricted as detailed in post we wrote about a previous false report of a vulnerability in the plugin). In one of the comments on the pull to make the change, one of the developers says as much. In relation to question about those not logged in uploading images they responded:

They shouldn’t be prevented from uploading files, just through the use of the Ajax endpoint. The forms should fallback to normal file uploads and work just fine.

That then brings us to a vulnerability report from the JPCERT/CC and IPA that relates to this. In that they state that prior to 1.26.2 the plugin failed “to restrict access permissions” and that “A remote unauthenticated attacker may upload an image file to the server.”. Considering as we already stated that even with the change those that didn’t already have an account can upload images by default, it’s not clear how if a vulnerability previously existed that it is now resolved.

What seems more problematic is what they list in the addendum section:

As of June 15th 2017, JPCERT/CC has received several incident reports of website defacements exploiting this issue.

We don’t understand how being able to upload an image by itself would lead to a website being defaced. The closest we could think of, without say using it with a local file inclusion (LFI) vulnerability, is that they are considering just being able to upload an arbitrary image and then link to it as a website defacement. But as we mentioned twice before, the change made doesn’t really fix that, so if that issue actually existed then it should still exist.

If this didn’t actually lead to website defacements than passing along an unfounded claim would fairly irresponsible of them.

In you have another thought that might explain the website defacement claim, please leave a comment.