PHP file upload bypass via Plugin installer
Package
WordPress
(WordPress)
Affected versions
>= 6.4.0 <6.4.3
>= 6.3.0 <6.3.3
>= 6.2.0 <6.2.4
>= 6.1.0 <6.1.5
>= 6.0.0 <6.0.7
>= 5.9.0 <5.9.9
>= 5.8.0 <5.8.9
>= 5.7.0 <5.7.11
>= 5.6.0 <5.6.13
>= 5.5.0 <5.5.14
>= 5.4.0 <5.4.15
>= 5.3.0 <5.3.17
>= 5.2.0 <5.2.20
>= 5.1.0 <5.1.18
>= 5.0.0 <5.0.21
>= 4.9.0 <4.9.25
>= 4.8.0 <4.8.24
>= 4.7.0 <4.7.28
>= 4.6.0 <4.6.28
>= 4.5.0 <4.5.31
>= 4.4.0 <4.4.32
>= 4.3.0 <4.3.33
>= 4.2.0 <4.2.37
<4.1.40
Patched versions
6.4.3
6.3.3
6.2.4
6.1.5
6.0.7
5.9.9
5.8.9
5.7.11
5.6.13
5.5.14
5.4.15
5.3.17
5.2.20
5.1.18
5.0.21
4.9.25
4.8.24
4.7.28
4.6.28
4.5.31
4.4.32
4.3.33
4.2.37
4.1.40
Impact
It's possible for a file of a type other than a zip file to be submitted as a new plugin by an administrative user on the Plugins -> Add New -> Upload Plugin screen in WordPress. If FTP credentials are requested for installation (in order to move the file into place outside of the
uploadsdirectory) then the uploaded file remains temporary available in the Media Library despite it not being allowed.If the
DISALLOW_FILE_EDITconstant is set totrueon the site and FTP credentials are required when uploading a new theme or plugin, then this technically allows an RCE when the user would otherwise have no means of executing arbitrary PHP code. This issue only affects Administrator level users on single site installations, and Super Admin level users on Multisite installations where it's otherwise expected that the user does not have permission to upload or execute arbitrary PHP code.DISALLOW_FILE_MODSconstant is set totrueare not affectedPatches
The issue was fixed in WordPress 6.4.3 on January 30, 2024 and backported to branches back to 4.1.
Workarounds
If the
DISALLOW_FILE_MODSconstant is defined astruethen it will not be possible for any user to upload a plugin and therefore this issue will not be exploitable.