The latest version of WordPress, 6.4.3, has created a lot of headaches for the WordPress community, as installing plugins by uploading most zipped copies of plugins that have been compressed on Macs are not working (and possibly zipped in some other situations). That is caused by fixing a vulnerability that was described in the release announcement as “a PHP File Upload bypass via Plugin Installer (requiring admin privileges).” That description isn’t clear, but seems rather odd. WordPress’ plugin installer intentionally allows uploading PHP files. It couldn’t work otherwise, as a WordPress plugin needs at least one PHP file. So how is this a vulnerability? It really isn’t.

So WordPress developers were fixing a vulnerability that really wasn’t a vulnerability and creating new problems. That seems like a bad trade to make. That is a larger problem than just this issue with WordPress. This often also occurs with WordPress plugins these days, when competitors of ours falsely claim there are vulnerabilities similar to the issue here and create unneeded headaches for others.

To get more technical about what was addressed, the following code was added to the file /wp-admin/includes/class-file-upload-upgrader.php:

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

if ( 'pluginzip' === $form || 'themezip' === $form ) {
	$archive_is_valid = false;
 
	/** This filter is documented in wp-admin/includes/file.php */
	if ( class_exists( 'ZipArchive', false ) && apply_filters( 'unzip_file_use_ziparchive', true ) ) {
		$archive          = new ZipArchive();
		$archive_is_valid = $archive->open( $file['file'], ZIPARCHIVE::CHECKCONS );
 
		if ( true === $archive_is_valid ) {
			$archive->close();
		}
	} else {
		require_once ABSPATH . 'wp-admin/includes/class-pclzip.php';
 
		$archive          = new PclZip( $file['file'] );
		$archive_is_valid = is_array( $archive->properties() );
	}
 
	if ( true !== $archive_is_valid ) {
		wp_delete_file( $file['file'] );
		wp_die( __( 'Incompatible Archive.' ) );
	}
}

That tries to make sure the plugin file being uploaded through the plugin isntall is a valid ZIP archive file. So it doesn’t change who has access to the plugin installer. Meaning an “attacker” would already be able to upload PHP files, so the attacker can still do what is supposed to be at issue.

Don’t take our word for it. Here was Wordfence’s explanation of this:

The first patch addresses an issue that allows users with Administrator (or Super Administrator on Multisite) privileges to upload PHP files directly to a site via the Plugin and Theme file upload mechanism. This is only a concern in heavily locked-down configurations that disallow Administrators and Super Administrators from installing plugins and themes via a separate mechanism. Wordfence has tracked this as a low-priority informational security alert since August 2023, though it has been public since August 2018.

If it has been public since August 2018, why address it only now?

It is worth noting that WordPress described this as a vulnerability, but Wordfence didn’t describe it that way. They did recently describe as a “vulnerability” a claimed issue in a WordPress plugin that allowed Administrators to upload PHP files. They also claimed it was a critical issue. A discussion on the support forum for the plugin about that gives some idea of the problem that sort of claim creates for the WordPress community.

Making a clear distinction between vulnerabilities and security issues that are less than vulnerabilities shouldn’t be hard, but unfortunately, many in the security community fail to do that. In the WordPress plugin vulnerabilities data space, that seems to be caused, at least in part, on inflating the count of vulnerabilities that are in data sets and generally lack of concern for accuracy.

You can follow the discussion on trying to address the bug in WordPress 6.4.3 in the relevant Trac ticket.