In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use, we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports, we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular, are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to the level of getting their own post, we now place them in a weekly post when we come across them.

Arbitrary File Deletion in Ninja Forms

Patchstack recently claimed that there had been an arbitrary file deletion vulnerability in Ninja Forms. They, in part, described that this way:

This could allow a malicious actor to delete files from your website.

They also claimed the required privilege to exploit this was the Administrator role. If that is the case, this wouldn’t really be a vulnerability, since normally Administrators can use their capabilities to delete arbitrary files.

Patchstack didn’t provide the information needed to easily check on their claim, but looking at the changes made in the version that this was claimed to have been fixed in, we found that this involved an action accessed through the WordPress REST API. The permission callback for that was the function get_submissions_permission_callback(), which is located in the file /includes/Routes/Submissions.php/:

175
176
177

'callback' => [ $this, 'delete_download_file' ],
// Uses the same permissions as the `download-all` request
'permission_callback' => [ $this, 'get_submissions_permission_callback' ],

That restricts access to it to Administrators:

241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256

public function get_submissions_permission_callback(WP_REST_Request $request) {
 
	//Set default to false
	$allowed = false;
 
	// Allow only admin to export personally identifiable data
	$permissionLevel = 'manage_options';  
	$allowed= \current_user_can($permissionLevel);
 
	/**
	 * Filter permissions for Reading Submissions
	 *
	 * @param bool $allowed Is request authorized?
	 * @param WP_REST_Request $request The current request
	 */
	return apply_filters( 'ninja_forms_api_allow_get_submissions', $allowed, $request );

So there wasn’t really a vulnerability. In line with that, the changelog described that as a bugfix.

The change made does look to properly restrict what can be deleted.

Plugin Security Scorecard Grade for Ninja Forms

See issues causing the plugin to get less than A+ grade